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

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

Hi Andy,

On 15.01.25 16:16, Andy Shevchenko wrote:
> On Wed, Jan 15, 2025 at 9:03 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>> 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?
> 
> Because (if follow your logic!) it won't ever happen until all the
> platforms that are using the non-dynamic bases are being removed as
> well.
>
> Otherwise this situation isn't anyhow different to the broken platform
> as you described.

Sorry, it's not clear to me why non-dynamic-bases can't be removed
at the same time that SysFS itself is removed. Can you explain?

>>>> 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.
> 
> It's not the same. If you still want to compare, then it means that
> what I suggest is to move from Reiser to say XFS.

I made a chart.

Starting position is that both ReiserFS and GPIO SysFS are going to be removed.

                +------------------------------------------------------------------------+
                | File System                       | GPIO                               |
+---------------+-----------------------------------+------------------------------------+
| Sensible      | Use XFS. ReiserFS will be         | Use libgpiod. /sys/class/gpio will |
|               | removed in future.                | be removed in future               |
+---------------+-----------------------------------+------------------------------------+
| User-hostile  | Mounting will jumble your inodes  | Booting will jumble your GPIOs     |
|               | and possibly corrupt your FS.     | and possibly brick your board.     |
+---------------+-----------------------------------+------------------------------------+

I believe the second row is bad and I don't want it for i.MX
users (or any users for that matter).

>> 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
> 
> I understand that, but what the series is trying to do is to put on
> hold _any_ sysfs removal activity along with reducing test coverage
> and motivation to fix the certain platform to work with dynamic base.

Why can't consumers of the static base be removed and then when none
are left, the base goes away too. Why does it have to be the other
way round?

> So, prepare your scripts not to toggle arbitrary numbers then and use libgpiod.

The SoC's own GPIO controllers have had deterministic numbering
for a long time. What would make them arbitrary is setting the base
to -1.

> P.S. I think this discussion goes nowhere. Talk to the GPIO
> maintainers for the matter, 

I believe that's what I am doing now?

> I'm not preventing you to put on hold GPIO
> development for _this_ platform, but I'm strongly against that because
> of your platform others should also be on hold, hence my NAK for that
> gpiolib patch.

Can you explain or point me at resources to understand why a static base
is blocking GPIO development subsystem-wide?

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 |