On Tue, Jan 14, 2025 at 10:55 AM Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> 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