Re: [rfc, PATCH v1 1/1] gpiolib: Get rid of never false gpio_is_valid() calls

[Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>]

On Wed, Apr 17, 2024 at 10:47:23PM +0200, Bartosz Golaszewski wrote:
> On Wed, Apr 17, 2024 at 12:46 PM Andy Shevchenko
> <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
> > On Tue, Feb 27, 2024 at 02:06:05PM +0100, Bartosz Golaszewski wrote:
> > > On Wed, Feb 21, 2024 at 10:32 PM Andy Shevchenko
> > > <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
> > > >
> > > > In the cases when gpio_is_valid() is called with unsigned parameter
> > > > the result is always true in the GPIO library code, hence the check
> > > > for false won't ever be true. Get rid of such calls.
> > > >
> > > > While at it, move GPIO device base to be unsigned to clearly show
> > > > it won't ever be negative. This requires a new definition for the
> > > > maximum GPIO number in the system.
> >
> > > > ---
> > >
> > > It looks like a risky change that late in the release cycle. I want to
> > > avoid some CI problems at rc6. Please resend it once v6.9-rc1 is
> > > tagged.
> >
> > Not sure why resend, but I missed that somehow. Can you consider applying it?
> 
> Applied, thanks!

Thank you!

I have grepped the kernel sources for these use cases:

  $ git grep -n -C6 '= devm_gpio_request([^A-Z]'
  $ git grep -n -C6 '= gpio_request([^A-Z]'

to see how many users might not have checked the validness of the GPIO before
passing to gpio_request(). All what I found is something like ~10 drivers.

They are basically in the risk category of my change.

Another risky part that touches everybody is the base finding algo.
I spent quite a time before sending this patch and looked at it again
to see if there is any potential flaw, but found nothing. Hopefully
we will see no reports or many and sooner than later while it sits
in Linux Next.

TL;DR: the above is a note to be in archives just in case.

-- 
With Best Regards,
Andy Shevchenko