| 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
Hello Bartosz, On 15.01.25 17:52, Bartosz Golaszewski wrote: > 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 the goal is to have a drop-in replacement for sysfs outside of the kernel, I think it needs to maintain the same numbering. I am not sure I see myself using it, because the new projects are using libgpiod from the get-go. My issue is not with removal of sysfs, but with user hostile deprecation approaches. > 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? Many GPIOs tend to not have labels. I think the mapping config file should rather map GPIO controllers to a base address. The same thing the kernel is currently doing. This assumes the numbering of the built-in GPIO controllers is deterministic, e.g. by consulting /aliases. I haven't checked, but I hope this is already the case. Cheers, Ahmad > > Bartosz > > [1] https://github.com/brgl/gpiod-sysfs-proxy >
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
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> On Mon, 13 Jan 2025 23:19:08 +0100, Ahmad Fatoum 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. > > [...] Applied, thanks! [3/4] gpio: mxc: remove dead code after switch to DT-only commit: b049e7abe9001a780d58e78e3833dcceee22f396 Best regards,
On Tue, Jan 21, 2025 at 11:37 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote: > > Hello Bartosz, > > On 15.01.25 17:52, Bartosz Golaszewski wrote: > > > > 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 the goal is to have a drop-in replacement for sysfs outside > of the kernel, I think it needs to maintain the same numbering. > > I am not sure I see myself using it, because the new projects are using > libgpiod from the get-go. My issue is not with removal of sysfs, but with > user hostile deprecation approaches. > > > 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? > > Many GPIOs tend to not have labels. I think the mapping config file > should rather map GPIO controllers to a base address. The same thing the > kernel is currently doing. This assumes the numbering of the built-in > GPIO controllers is deterministic, e.g. by consulting /aliases. I haven't > checked, but I hope this is already the case. Well, they will have labels, it's just that the label will be something like "6e80000.gpio" which can very well be mapped onto a predefined GPIO range. The file could look like: /etc/gpio-static-base.conf ``` 6e80000.gpio 12 foobar 340 ``` Where the first column is the label and the second the static base that must be less than 512 - ngpio. Bart
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,