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

[Ahmad Fatoum <a.fatoum@pengutronix.de>]

Hello Andy,

On 14.01.25 20:43, Andy Shevchenko wrote:
> On Tue, Jan 14, 2025 at 11:55 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>> 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.

Please read my cover letter / commit messages. I do nowhere object to deprecation
and removal of the sysfs interface. But I strongly disagree that a necessary step
towards that is having Linux start toggling random GPIOs after an update on
platforms that behaved consistently for >10 years.

Can you explain why we can't remove the hardcoded base at the same time that
sysfs support is removed for good?

>>> 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?
> 
> Exactly, Which means "tend to get never fixed".

Imagine ReiserFS deprecation strategy involved shipping an update that
just corrupted your existing file system and developers insisted on calling
it a fix, as ReiserFS is going to be removed anyway.

>>> 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?
> 
> Yes, try to write your scripts based on the libgpiod or the tools
> provided by the project. I.o.w. follow the warning that SYSFS will be
> removed at some point and prepare yourself for that. If some kernel
> work needs to be done, contribute.

I have been using libgpiod for many years, but have in the past used sysfs
or been involved with projects using sysfs. I agree that these projects
need to switch to the GPIO character device and that they will be eventually
broken. Yet, I still get warnings despite doing everything correctly IMO and no,
I don't want to fix a warning by doing negligent stuff like jumble GPIO numbers,
with the reason that it's going to be broken for good in the future anyway.

To reiterate, my issue is with the manner of breakage:

  - broken, because /sys/class/gpio doesn't exist: good
  - broken, because script executes successfully, but toggles arbitrary pins: bad

Thanks,
Ahmad

> 


-- 
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 |