Re: [PATCH 1/4] gpiolib: add opt-out for existing drivers with static GPIO base

[Kent Gibson <warthog618@gmail.com>]

On Wed, Jan 15, 2025 at 08:07:38AM +0100, Ahmad Fatoum wrote:
> On 14.01.25 20:38, Andy Shevchenko wrote:
> > On Tue, Jan 14, 2025 at 12:06 PM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> >> On 14.01.25 10:49, Andy Shevchenko wrote:
> >>> On Tue, Jan 14, 2025 at 12:20 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> >>>>
> >>>> Some drivers have had deterministic GPIO numbering for most of
> >>>> their existence, e.g. the i.MX GPIO since commit 7e6086d9e54a
> >>>> ("gpio/mxc: specify gpio base for device tree probe"), more than
> >>>> 12 years ago.
> >>>>
> >>>> Reverting this to dynamically numbered will break existing setups in
> >>>> the worst manner possible: The build will succeed, the kernel will not
> >>>> print warnings, but users will find their devices essentially toggling
> >>>> GPIOs at random with the potential of permanent damage.
> >>>>
> >>>> As these concerns won't go away until the sysfs interface is removed,
> >>>> let's add a new struct gpio_chip::legacy_static_base member that can be
> >>>> used by existing drivers that have been grandfathered in to suppress
> >>>> the warning currently being printed:
> >>>>
> >>>>   gpio gpiochip0: Static allocation of GPIO base is deprecated,
> >>>>   use dynamic allocation.
> >>>
> >>> Warning is harmless and still a good reminder for the stuff that needs
> >>> more love.
> >>> NAK.
> >>
> >> A warning is a call-to-action and it's counterproductive to keep tricking
> >> people into removing the static base and breaking other users' scripts.
> >
> > Are you prepared to say the same when the entire GPIO SYSFS will be
> > removed? Because that's exactly what I referred to in the reply to the
> > cover letter as an impediment to move forward.
>
> No. But this gives me an idea: We could make the warning dependent
> on CONFIG_GPIO_SYSFS and add a comment to the i.MX code suggesting
> users do that instead. What do you think?
>

AIUI, the purpose of the warning is to remind driver authors, not end users,
to update their drivers, as the old behaviour is deprecated. That is
independent of GPIO SYSFS - that just happens to be something that makes the
change visible to userspace.

Rather than making the warning conditional, how about making the fix for the
warning in your driver, so switching to dynamic allocation, conditional on
CONFIG_GPIO_SYSFS not being set?
That would provide a path forward for users that want to dispense with
the warning - as long as they dispense with GPIO SYSFS.

Cheers,
Kent.