| Message ID | 20250113-b4-imx-gpio-base-warning-v1-0-0a28731a5cf6@pengutronix.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | gpio: mxc: silence warning about GPIO base being statically allocated | expand |
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. 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.
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? Cheers, Ahmad
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. > > > > 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". > > 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.
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 >
On Wed, Jan 15, 2025 at 9:03 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote: > 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? 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.
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
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,