On Fri, Jan 12, 2024 at 01:16:29PM +0000, Westermann, Oliver wrote: > > > 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) > Sorry for the belated reply, but just to clarify where I am with this: This looks like an init-time problem, more so than a runtime, so you should pursue the init-time solutions and exhaust your options there before looking to solve it via the GPIO uAPI. Cheers, Kent.