linux-kernel - Re: [PATCH 2/5] mfd: lm3533-ctrlbank: Cap BRIGHTNESS

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Mon, 29 Jun 2020 14:25:06 +0100
From:   Lee Jones <lee.jones@...aro.org>
To:     Johan Hovold <johan@...nel.org>
Cc:     linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Johan Hovold <jhovold@...il.com>
Subject: Re: [PATCH 2/5] mfd: lm3533-ctrlbank: Cap BRIGHTNESS_MAX to 127
 since API uses u8 as carrier

On Mon, 29 Jun 2020, Johan Hovold wrote:

> On Mon, Jun 29, 2020 at 01:32:12PM +0100, Lee Jones wrote:
> > Since its conception in 2012 brightness has been artificially capped
> > at 127 since the variable carrying the value is u8.  We could go to
> > the trouble of changing the whole API (crossing 3 different subsystems),
> > but clearly this hasn't bothered anyone in the best part of a decade.
> > 
> > Simply, cap BRIGHTNESS_MAX to 127 instead (for now at least).
> 
> Hmm. This patch is clearly broken and would contrary to the claim be
> introducing an artificial cap at half brightness. u8 can hold the max
> brightness value 255 just fine.

Yes, of course it can.  Senior moment on my account.

> > Fixes the following W=1 warning(s):
> > 
> >  drivers/mfd/lm3533-ctrlbank.c: In function ‘lm3533_ctrlbank_set_brightness’:
> >  drivers/mfd/lm3533-ctrlbank.c:98:10: warning: comparison is always false due to limited range of data type [-Wtype-limits]
> >  98 | if (val > LM3533_##_NAME##_MAX) | ^
> >  drivers/mfd/lm3533-ctrlbank.c:125:1: note: in expansion of macro ‘lm3533_ctrlbank_set’
> >  125 | lm3533_ctrlbank_set(brightness, BRIGHTNESS);
> >  | ^~~~~~~~~~~~~~~~~~~
> 
> This warning is benign. The same macro is used to defined two function
> where in one case the max value coincides with U8_MAX so that the sanity
> check becomes redundant.

A benign warning, as most W=1 warnings are, is still a warning.

So how do you propose we fix it?

Is 255 a valid and used brightness level?

If so, how do you feel about:

  /* Avoid 'always false' check '(u8) > 255' */
  if (LM3533_##_NAME##_MAX != 0xff && val > LM3533_##_NAME##_MAX)
          return -EINVAL;        

> > Cc: Johan Hovold <jhovold@...il.com>
> > Signed-off-by: Lee Jones <lee.jones@...aro.org>
> > ---
> >  drivers/mfd/lm3533-ctrlbank.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/mfd/lm3533-ctrlbank.c b/drivers/mfd/lm3533-ctrlbank.c
> > index 34fba06ec7057..348ce67453092 100644
> > --- a/drivers/mfd/lm3533-ctrlbank.c
> > +++ b/drivers/mfd/lm3533-ctrlbank.c
> > @@ -17,7 +17,7 @@
> >  #define LM3533_MAX_CURRENT_MAX		29800
> >  #define LM3533_MAX_CURRENT_STEP		800
> >  
> > -#define LM3533_BRIGHTNESS_MAX		255
> > +#define LM3533_BRIGHTNESS_MAX		127  /* Capped by API - could be up to 255 */
> >  #define LM3533_PWM_MAX			0x3f
> >  
> >  #define LM3533_REG_PWM_BASE		0x14
> 
> Johan

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog