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

[Ahmad Fatoum]

Hello Bartosz,

On 15.01.25 17:52, Bartosz Golaszewski wrote:
> On Tue, Jan 14, 2025 at 10:55 AM Ahmad Fatoum <a.fatoum at 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 at 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 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.

Cheers,
Ahmad

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


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |