Re: Re: Assign line names at runtime

["Westermann, Oliver" <Oliver.Westermann@xxxxxxxxxx>]

You mean you specify those in .dts?

On Fri, Jan 12, 2024 at 9:33 Alexander Dahl wrote:
> Am Thu, Jan 11, 2024 at 10:42:51AM +0000 schrieb Westermann, Oliver:
> > We're transitioning from using the old sysfs interface to using
> > gpiod and named lines. For most devices, we specify line names at
> > boot time using gpio-line-names.
> 
> You mean you specify those in .dts?

Yes, currently we define the full GPIO expanders in .dts, bus, address, gpio-line-names.

> > On some devices we have small differences between revisions or
> > hardware variants, which causes lines to be swapped on GPIO
> > expanders or just being used differently for between revisions. We
> > started to handle this by overlays, but that requires to distinguish
> > during the bootloader phase, which is hard to service and often
> > unneeded. Especially when we want to rename a single line, the
> > overlay needs to override all entries, which leads to duplication of
> > those line name lists.
> 
> So essentially you have hardware variants.  In my opinion this should
> be handled in the bootloader.  What about having a .dtsi for the
> common part of the board, one .dts file for each variant, and the
> bootloader picking the correct one?  This is probably less complicated
> than handling with overlays.  Overlays are designated for a different
> use case like add-on boards, aren't they?

In general, I'm focusing on the add-on boards. For the baseboards, we can work
with .dtb(i/o), as the mutations are limited and changes are rare, so those can
be handled using in the bootloader. But our add-on boards are plentyful and
have variants with revisions each. Supporting them all in bootloader/dtb means
regular updates to low-level code, which feels like we can simplify and derisk
it.

On Fri, Jan 12, 2024 at 1:31 AM Kent Gibson wrote:
> So I'm at the point that I think we could do it, one way or another, but
> much less certain if we should.
> I would not consider it if there was an alternative.

I played around a bit this morning and I have a (probably hacky but) working
prototype which adds a GPIO_V2_SET_LINEINFO_IOCTL and currently only allows to
override a line name. I played around a bit and tried to break something, but
currently, it seems to work. But I'm also open for any alternative, so maybe
with some extra info, somebody has better ideas:

The hardware variants I'm dealing with could be considered accessories:
Extension of a base in different kind and revisions. As those, they are mostly
not boot critical - I can defer probing. That would also allow me to defer
probing up until manual probing from userspace, eg by a udev rule collecting
more data and providing that to the driver once all data is present.

Could e.g. an extension of the modprobe params for i2c gpiochip drivers allow to
provide not only bus and address, but also a list of pin names? Ideally
implemented on the gpiochip / i2c gpio level so this applies to all gpio drivers?

(new attempt at manual formatting, sorry)

Best regards, Olli