Re: [PATCH v5 6/8] hw/i2c: parent slaves created with i2c_slave_create_simple

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