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 for Android: free password hash cracker in your pocket

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

Message-ID: <20200630083810.GY3334@localhost>
Date:   Tue, 30 Jun 2020 10:38:10 +0200
From:   Johan Hovold <johan@...nel.org>
To:     Lee Jones <lee.jones@...aro.org>
Cc:     Johan Hovold <johan@...nel.org>,
        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, Jun 29, 2020 at 02:25:06PM +0100, Lee Jones wrote:
> 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.

Not every warning needs to be addressed, there's a reason some of these
are hidden behind W=1 or higher.

> So how do you propose we fix it?
> 
> Is 255 a valid and used brightness level?

Yes.

> If so, how do you feel about:
> 
>   /* Avoid 'always false' check '(u8) > 255' */
>   if (LM3533_##_NAME##_MAX != 0xff && val > LM3533_##_NAME##_MAX)
>           return -EINVAL;        

I'm afraid that's not sufficient to shut the compiler up.

I'll send you patch expanding these accessors instead. Having exported
functions implemented by macros is particularly nice (hard to grep for
etc). There are a couple of more sets of control-bank registers that
could potentially have shared the implementation and which motivated the
use of macros, but it does not seem very likely that we'll be adding
those anytime soon anyway.

Johan