On Fri, 17 Jul 2026 at 13:57, Corey Minyard <[email protected]> wrote: > > On Thu, Jul 16, 2026 at 07:08:04PM +0200, Emmanuel Blot wrote: > > > > > > On 10 Jul 2026, at 18:05, Peter Maydell wrote: > > > > > On Wed, 1 Jul 2026 at 18:31, Emmanuel Blot <[email protected]> wrote: > > >> > > >> Slaves created with i2c_slave_create_simple() were left unparented and > > >> showed up under /machine/unattached with no stable QOM path. Add each > > >> slave as a QOM child of its bus, named after its I2C address, so it has > > >> a deterministic and addressable QOM path. > > > > > > Should devices on a bus be QOM children of the bus, though? > > > I would expect that they ought to be QOM children of e.g. > > > the SoC or machine that created them. > > > > > > Do we do this for other bus types, e.g. PCI ? > > > > If we do not want a I2C device to be a child of its bus, an alternative > > parent could be the master/controller of the bus. However as a controller > > may manage several buses, we need to add bus differentiator in the child > > name, such as bus_num:address. > > > > I do not think it makes more sense to have the I2C device to be a child of > > the SoC rather than its dedicated controller. > > > > On machines that are statically defined rather than composed from the > > command line (BMCs, complex SoC-based machines, …), all the I2C devices > > would appear as a “flat” list of devices, with sometimes many instances of > > the same I2C device type belonging to very different sub-domains of the > > machine they instrument and/or drive. > > > > I tend to think that using a flat schema would likely make use of QOM paths > > more difficult to observe and reach a device at run time: one would have to > > iterate the device and bus hierarchy rather than to use QOM path to access > > a device, or special care would be required for naming device instances. I > > was viewing the role of the QOM paths as a way to expose the machine device > > hierarchy as a comprehensive and non-ambiguous representation. > > > > What are the cons for using the device/bus hierarchy for simple buses such > > as SPI & I2C? > > Is there any drawback to use the device & bus hierarchy to assign a > > default/fallback QOM path to a device? > > > > Maybe it’s a matter of ownership? Neither the I2C. bus nor the I2C > > controller owns the device for sure. > > Well, "own" doesn't have much of a meaning in this context. It's a > matter of how it's connected.
"own" is the whole thing about the QOM tree, though. This is specifically not the same thing as how a device is connected. > I agree with you philosophically. From a user's point of view, a > hierarchy is much more obvious. Otherwise you will have to create a > fake hierarchy with the names or you won't be able to find anything. If you want the bus hierarchy, we have that; it's not the same thing as the QOM ownership hierarchy. -- PMM
