Message-ID: <CAHp75VfZHZ7Xx1SnryBX683B=gm70SE_bvhivn+ecUePebQLdA@mail.gmail.com>
Date: Wed, 15 Jan 2025 17:16:53 +0200
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Ahmad Fatoum <a.fatoum@...gutronix.de>
Cc: Linus Walleij <linus.walleij@...aro.org>, Bartosz Golaszewski <brgl@...ev.pl>, 
	Andy Whitcroft <apw@...onical.com>, Joe Perches <joe@...ches.com>, 
	Dwaipayan Ray <dwaipayanray1@...il.com>, Lukas Bulwahn <lukas.bulwahn@...il.com>, 
	Fabio Estevam <festevam@...il.com>, Shawn Guo <shawnguo@...nel.org>, 
	Sascha Hauer <s.hauer@...gutronix.de>, Pengutronix Kernel Team <kernel@...gutronix.de>, 
	Dario Binacchi <dario.binacchi@...rulasolutions.com>, Haibo Chen <haibo.chen@....com>, 
	Catalin Popescu <catalin.popescu@...ca-geosystems.com>, linux-gpio@...r.kernel.org, 
	linux-kernel@...r.kernel.org, imx@...ts.linux.dev, 
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 0/4] gpio: mxc: silence warning about GPIO base being
 statically allocated

On Wed, Jan 15, 2025 at 9:03 AM Ahmad Fatoum <a.fatoum@...gutronix.de> wrote:
> On 14.01.25 20:43, Andy Shevchenko wrote:
> > On Tue, Jan 14, 2025 at 11:55 AM Ahmad Fatoum <a.fatoum@...gutronix.de> wrote:
> >> On 14.01.25 10:46, Andy Shevchenko wrote:
> >>> On Tue, Jan 14, 2025 at 12:19 AM Ahmad Fatoum <a.fatoum@...gutronix.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?

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.

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

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.

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

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.

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

P.S. I think this discussion goes nowhere. Talk to the GPIO
maintainers for the matter, 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.

-- 
With Best Regards,
Andy Shevchenko

Powered by blists - more mailing lists