Hi Greg, Sorry for answering in pieces. The DT question came up again in Krzysztof's review of the bindings, so I'd like to answer that part on its own. Jeremy asked much the same from the other side, why LSTP needs static configuration. The rest of your review (one function per interface, greybus) will follow once we have aligned internally, as I wrote earlier.
On Tue, Oct 13, 2026 at 01:37:11PM +0200, Greg Kroah-Hartman wrote: > Why would a USB device have anything to do with device tree? [...] > USB devices do not have DT bindings. It's a dynamic bus, with > self-describing devices, don't make the mistake of thinking this is > giong to work. The device itself is self-describing: the driver reads the channel table from it, and the channels work without any firmware description. What DT (or ACPI on host systems) adds is the board wiring behind the channels, which the device cannot describe, the same as for any other I2C or GPIO controller: - I2C channels carry devices the kernel has to instantiate: PMBus voltage regulator controllers, EEPROMs, GPIO expanders. Userspace can add a client with new_device, but only with a name and an address, no interrupt, GPIO or other properties, and only on a bus number that changes with USB enumeration. It would also have to repeat that every time the adapter re-enumerates; the kernel does it on its own when the channel appears. - GPIO lines get board-specific names from gpio-line-names. The adapter firmware reports generic pin names, the same firmware is used on different boards, and BMC userspace (power control, GPIO monitoring) looks lines up by name. - A GPIO channel can be the interrupt controller, or the GPIO provider, for another device on the board. Such references between devices have no userspace interface at all. On those boards the adapter is part of the board, not something a user plugs in, which is the case the generic USB device binding (Documentation/devicetree/bindings/usb/usb-device.yaml) covers; the LSTP nodes sit below that node. The DT part probably deserves its own thread with the DT maintainers rather than being buried in this one. The RFC posted with the series [1] has the open DT questions; I suggest we continue there, or in a new thread if you prefer. [1] https://lore.kernel.org/r/[email protected] Thanks, Adrian _______________________________________________ Openipmi-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openipmi-developer
