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