[igt-dev] [PATCH i-g-t] tests/kms_frontbuffer_tracking: Accept missing FBC debugfs files

Petri Latvala petri.latvala at intel.com
Thu Nov 25 10:24:29 UTC 2021


On Thu, Nov 25, 2021 at 12:09:25PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 25, 2021 at 11:59:30AM +0200, Petri Latvala wrote:
> > On Thu, Nov 25, 2021 at 11:50:06AM +0200, Ville Syrjälä wrote:
> > > On Wed, Nov 24, 2021 at 05:25:06PM +0200, Petri Latvala wrote:
> > > > On Wed, Nov 24, 2021 at 05:12:45PM +0200, Ville Syrjala wrote:
> > > > > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > > > 
> > > > > With multiple FBC instances becoming a thing at some point
> > > > > the current plan is to go with separate debugfs files for
> > > > > each FBC instance. Which also means that if there is no
> > > > > FBC there will be no debugfs files either. Adapt the test
> > > > > to tolerate such conditions.
> > > > > 
> > > > > Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > > > ---
> > > > >  tests/i915/kms_frontbuffer_tracking.c | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/tests/i915/kms_frontbuffer_tracking.c b/tests/i915/kms_frontbuffer_tracking.c
> > > > > index d6a884926c48..532bfbb9b481 100644
> > > > > --- a/tests/i915/kms_frontbuffer_tracking.c
> > > > > +++ b/tests/i915/kms_frontbuffer_tracking.c
> > > > > @@ -724,7 +724,7 @@ static void __debugfs_read(const char *param, char *buf, int len)
> > > > >  {
> > > > >  	len = igt_debugfs_simple_read(drm.debugfs, param, buf, len);
> > > > >  	if (len < 0)
> > > > > -		igt_assert_eq(len, -ENODEV);
> > > > > +		igt_assert(len == -ENOENT || len == -ENODEV);
> > > > 
> > > > If this fires, we now lose the information on what the error
> > > > was. Although we automatically print errno in that case, is the error
> > > > in there?
> > > 
> > > Not quite sure what you're asking here. But at least igt_assert() will
> > > still print the errno here, if that's what you're asking.
> > 
> > igt_assert_eq prints the value of "len" if it's not -ENODEV,
> > igt_assert doesn't. What I'm asking is whether igt_debugfs_simple_read
> > leaves the error it returns in errno. I could check but ECOFFEE.
> 
> Yes, errno seems to be preserved.
> 
> Quick check of the code agrees. Well, except for the case of close()
> failing after read() failed, which would clobber the errno from read().
> But close() failing would be pretty nuts.

Yeah.

Reviewed-by: Petri Latvala <petri.latvala at intel.com>


More information about the igt-dev mailing list