linux-kernel - Re: [PATCH 2/2] staging: sm750fb: Remove unused return value in program_mode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ZS/cp8IZyCjujmDQ@dorcaslitunya-virtual-machine>
Date:   Wed, 18 Oct 2023 16:24:55 +0300
From:   Dorcas Litunya <anonolitunya@...il.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Julia Lawall <julia.lawall@...ia.fr>, outreachy@...ts.linux.dev,
        dan.carpenter@...aro.org, andi.shyti@...ux.intel.com,
        Sudip Mukherjee <sudipm.mukherjee@...il.com>,
        Teddy Wang <teddy.wang@...iconmotion.com>,
        linux-fbdev@...r.kernel.org, linux-staging@...ts.linux.dev,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] staging: sm750fb: Remove unused return value in
 program_mode_registers()

On Wed, Oct 18, 2023 at 03:25:05PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Oct 18, 2023 at 12:34:26PM +0300, Dorcas Litunya wrote:
> > On Wed, Oct 18, 2023 at 11:26:33AM +0200, Greg Kroah-Hartman wrote:
> > > On Wed, Oct 18, 2023 at 12:07:38PM +0300, Dorcas AnonoLitunya wrote:
> > > > Modifies the return type of program_mode_registers()
> > > > to void from int as the return value is being ignored in
> > > > all subsequent function calls.
> > > > 
> > > > This improves code readability and maintainability.
> > > > 
> > > > Suggested-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> > > > Signed-off-by: Dorcas AnonoLitunya <anonolitunya@...il.com>
> > > > ---
> > > >  drivers/staging/sm750fb/ddk750_mode.c | 5 ++---
> > > >  1 file changed, 2 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/drivers/staging/sm750fb/ddk750_mode.c b/drivers/staging/sm750fb/ddk750_mode.c
> > > > index 83ace6cc9583..e15039238232 100644
> > > > --- a/drivers/staging/sm750fb/ddk750_mode.c
> > > > +++ b/drivers/staging/sm750fb/ddk750_mode.c
> > > > @@ -73,8 +73,8 @@ display_control_adjust_sm750le(struct mode_parameter *mode_param,
> > > >  }
> > > >  
> > > >  /* only timing related registers will be  programed */
> > > > -static int program_mode_registers(struct mode_parameter *mode_param,
> > > > -				  struct pll_value *pll)
> > > > +static void program_mode_registers(struct mode_parameter *mode_param,
> > > > +				   struct pll_value *pll)
> > > >  {
> > > >  	int ret = 0;
> > > >  	int cnt = 0;
> > > > @@ -202,7 +202,6 @@ static int program_mode_registers(struct mode_parameter *mode_param,
> > > >  	} else {
> > > >  		ret = -1;
> > > 
> > > Why are you still setting the 'ret' variable if you are not doing
> > > anything with it anymore?
> > > 
> > > >  	}
> > > > -	return ret;
> > > 
> > > Are you sure that the caller shouldn't be checking for errors instead of
> > > dropping the return value?  If so, document that in the changelog too.
> > >
> > Seems like the caller doesn't use the function to check for errors as in
> > the code below:
> > 
> > int ddk750_set_mode_timing(struct mode_parameter *parm, enum clock_type clock)
> > {
> >         struct pll_value pll;
> > 
> >         pll.input_freq = DEFAULT_INPUT_CLOCK;
> >         pll.clock_type = clock;
> > 
> >         sm750_calc_pll_value(parm->pixel_clock, &pll);
> >         if (sm750_get_chip_type() == SM750LE) {
> >                 /* set graphic mode via IO method */
> >                 outb_p(0x88, 0x3d4);
> >                 outb_p(0x06, 0x3d5);
> >         }
> >         program_mode_registers(parm, &pll);
> >         return 0;
> > 
> > It will still return 0 regardless of whether there is an error or not.
> > Since I am not sure how the two functions relate to one another, is
> > there need to check error in the caller function?
> 
> That is correct, it is not checking for errors, but shouldn't it?  If
> the function can fail, then it should have proper error handling so
> return the correct error (hint -1 is not a valid error), and then
> propagate it up the call chain correctly as well.
> 
> For doing this type of work, either the function can not fail so there
> can not be an error return value, or it can, and then the error should
> be propagated correctly.  Sorry for not spelling that out earlier.
> 
> thanks,
> 
> greg k-h
Makes sense. I am not sure whether there exists a function that cannot
fail. But for this patch I will start by assuming that it cannot fail and
remove the error return variable altogether. Then after submission of the patch, I
will look at whether the function can fail and see how to propagate the
error. I think this should work?

thanks,
Dorcas