Re: Replacing global GPIO numbers in sysfs with hardware offsets

[Kent Gibson <warthog618@xxxxxxxxx>]

On Wed, Feb 26, 2025 at 10:23:37AM +0100, Bartosz Golaszewski wrote:
> On Mon, Feb 24, 2025 at 2:49 AM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> >
> >
> > As it stands the user needs to search the gpiochipXYZs looking for the
> > matching label. It would be easier if the chip was identified in sysfs by
> > its label, rather than (as well as) its base address.
> > So no searching required.
> >
>
> TBH that's technically easy and backward compatible - just have a link
> named after the label pointing to the chip.
>
> > Aside: Speaking of which, once the global numberspace is removed does
> > exposing the base address serve any purpose?
> >
>
> Good point, at this point we'd have to switch to fully identifying
> chips by label and possibly the device name (gpiochipX, not
> gpiochip$BASE).
>

That works for me.  Though are chip labels quaranteed unique?

> > Similarly, it would be even simpler if the line could be exported by
> > name, so the user wouldn't need to pull magic chip labels and offsets out
> > of the air.
> > Though that would be a much more extensive change.
> >
> > Btw, I am well aware that line names are not guaranteed unique, so this
> > approach would only be viable/enabled (potentially on a line by line
> > basis) where they are - and that would provide some incentive for them to
> > be made unique downstream, if not in mainline.
> >
> > > Bart
> > >
> > > [1] https://fosdem.org/2025/schedule/event/fosdem-2025-5288-the-status-of-removing-sys-class-gpio-and-the-global-gpio-numberspace-from-the-kernel/
> >
> > My primary takeaway from your talk is that you are more of a thrill
> > seeker than I am comfortable with - making jokes about Rust in a
> > live forum - THAT is living on the edge ;).
> >
> > Wrt the Q&A at 19:42 - the Pi BCM driver with its module parameter and
> > "why only this one driver is allowed to have it and the others not" and
> > the suggestion that there be some flag that can be passed to the driver
> > to request persistence:  I don't like your answer - it conflates specifying
> > the default/safe state, generally defined at boot time, with an ability to
> > override that at runtime.
>
> Yeah I was taken by surprise, I wasn't aware of the RPi driver having
> this parameter.
>
> > Extending the driver API to allow the gpio_chip user to request that the
> > driver NOT reset an output to its default state when released seems like a
> > viable solution to me.  Am I missing something?
> >
>
> This is not that simple actually. struct gpio_chip has the .free()
> callack which leaves to the driver the freedom to do anything at
> release - including reverting the state or not. What and when should
> the core framework code do then? But I'm not saying no if we can have
> a good solution here.
>

That is exactly the point - the driver has the freedom to do whatever
once .free() is called.  What I am suggesting is that while the user has
the line requested they could set a flag, say via .set_config(), to request
the driver NOT to revert the line, but to leave it as is when freed.
That would stand until the next time the line is requested when the flag
would automatically be cleared.

It would be opt-in, so the driver would not have to support it.
And it could be exposed to userspace via a flag in the uAPI.

> > It also didn't address the fact that, even at FOSDEM, there are developers
> > out there that think that some drivers are getting special treatment.
> > In this case the Pi devs have pushed their own downstream solution
> > upstream to reduce their own maintenance burden.  And that was accepted as
> > it didn't conflict with anything in mainline.
> > There is nothing preventing other drivers doing the same, though no one
> > has AFAIAA.
> > Though the module parameter solution is rather crude - if we are going to
> > start touching all the drivers then why not address it via the API?
> >
>
> I don't know the history of this. It's a driver under drivers/pinctrl/
> and I was never Cc'ed on the patch that added it. I probably would
> have objected to doing it inside an individual module.
>

Actually you were on the cc list[1], as was I, but it was a pinctrl change
so you probably skimmed over it.
I only looked at it as the bcm caught my eye, and I'm somewhat familiar
with how the Pi devs addressed the gpioset persistence issue downstream.

I wasn't totally comfortable with the change either, certainly not as a
general solution, but it was contained to the module so I didn't object -
I figured either you or Linus would if it bothered you.

Cheers,
Kent.

[1] https://lore.kernel.org/linux-gpio/20240503062745.11298-1-wahrenst@xxxxxxx/