[0/4] gpio: mxc: silence warning about GPIO base being statically allocated

The i.MX GPIO driver has had deterministic numbering for the GPIOs
for more than 12 years.

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. We thus want to keep
the numbering as-is until the SysFS API is removed and script fail
instead of toggling GPIOs dependent on probe order.

Yet, the warning:

  gpio gpiochip0: Static allocation of GPIO base is deprecated,
  use dynamic allocation.

is annoying and prompts people to set the base to -1 from time to time.

Let's workaround this by adding an opt-out for existing drivers and have
i.MX make use of it.

---
Ahmad Fatoum (4):
      gpiolib: add opt-out for existing drivers with static GPIO base
      checkpatch: warn about use of legacy_static_base
      gpio: mxc: remove dead code after switch to DT-only
      gpio: mxc: silence warning about GPIO base being statically allocated

 drivers/gpio/gpio-mxc.c     | 23 +++++++++++++++++++++--
 drivers/gpio/gpiolib.c      |  2 +-
 include/linux/gpio/driver.h |  5 +++++
 scripts/checkpatch.pl       | 11 +++++++++--
 4 files changed, 36 insertions(+), 5 deletions(-)
---
base-commit: 37136bf5c3a6f6b686d74f41837a6406bec6b7bc
change-id: 20250113-b4-imx-gpio-base-warning-4f9ae89887d0

Best regards,

On Tue, Jan 14, 2025 at 10:55 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>
> Hi Andy,
>
> On 14.01.25 10:46, Andy Shevchenko wrote:
> > On Tue, Jan 14, 2025 at 12:19 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> >>
> >> The i.MX GPIO driver has had deterministic numbering for the GPIOs
> >> for more than 12 years.
> >>
> >> 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. We thus want to keep
> >> the numbering as-is until the SysFS API is removed and script fail
> >> instead of toggling GPIOs dependent on probe order.
> >
> > While I understand the issue this tends to get never fixed until the
> > entire support of iMX boards will be dropped.
>
> i.MX is an actively developed and widely used platform. Why should support
> be dropped?
>
> > Personally I do not like
> > this series at all. Rather let's try to go the hard way and understand
> > what's going on to fix the current issues.
>
> /sys/class/gpio is deprecated and when it is finally removed, this series can
> be reverted again. The alternatives are either do nothing and live with 6 kernel
> warnings cluttering every boot or show users the finger as described in
> the cover letter.
>
> Do you see a different path forward?
>

I recently wrote a user-space compatibility layer for sysfs[1]. While
right now it doesn't support static base numbers, I'm very open to
adding it except that I wasn't sure how to approach it.

Is this of any use to you and could it help you switch to libgpiod
without changing your user-space set-up (given the support for static
GPIO numbering)? If so, how would you like to see this implemented? A
config file at /etc that would list chip labels and their desired GPIO
base?

Bartosz

[1] https://github.com/brgl/gpiod-sysfs-proxy

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>


On Mon, 13 Jan 2025 23:19:08 +0100, Ahmad Fatoum wrote:
> The i.MX GPIO driver has had deterministic numbering for the GPIOs
> for more than 12 years.
> 
> 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. We thus want to keep
> the numbering as-is until the SysFS API is removed and script fail
> instead of toggling GPIOs dependent on probe order.
> 
> [...]

Applied, thanks!

[3/4] gpio: mxc: remove dead code after switch to DT-only
      commit: b049e7abe9001a780d58e78e3833dcceee22f396

Best regards,

On Tue, Jan 21, 2025 at 11:37 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>
> Hello Bartosz,
>
> On 15.01.25 17:52, Bartosz Golaszewski wrote:
> >
> > I recently wrote a user-space compatibility layer for sysfs[1]. While
> > right now it doesn't support static base numbers, I'm very open to
> > adding it except that I wasn't sure how to approach it.
> >
> > Is this of any use to you and could it help you switch to libgpiod
> > without changing your user-space set-up (given the support for static
> > GPIO numbering)?
>
> If the goal is to have a drop-in replacement for sysfs outside
> of the kernel, I think it needs to maintain the same numbering.
>
> I am not sure I see myself using it, because the new projects are using
> libgpiod from the get-go. My issue is not with removal of sysfs, but with
> user hostile deprecation approaches.
>
> > If so, how would you like to see this implemented? A
> > config file at /etc that would list chip labels and their desired GPIO
> > base?
>
> Many GPIOs tend to not have labels. I think the mapping config file
> should rather map GPIO controllers to a base address. The same thing the
> kernel is currently doing. This assumes the numbering of the built-in
> GPIO controllers is deterministic, e.g. by consulting /aliases. I haven't
> checked, but I hope this is already the case.

Well, they will have labels, it's just that the label will be
something like "6e80000.gpio" which can very well be mapped onto a
predefined GPIO range.

The file could look like:

/etc/gpio-static-base.conf

```
6e80000.gpio 12
foobar 340
```

Where the first column is the label and the second the static base
that must be less than 512 - ngpio.

Bart