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

[Corey Minyard <cminyard@mvista.com>]

[-- Attachment #1: Type: text/plain, Size: 3735 bytes --]

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 <emmanuel.blot@free.fr> 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.

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.

I looked at https://lore.kernel.org/qemu-devel/87se5scipx.fsf@pond.sub.org/
but not much came of that.

It would be ideal if the hierarchy was a natural part of the APIs that
register a device.  If you put a device on an I2C bus, it becomes a
child of that I2C bus automatically.

However, corner cases exist.  Multi-master I2C chips would have two
parent I2C busses connected to a single child I2C bus, for instance.
Anything multi-master would have this issue.  Thinking about it some
more, a PHY might be on an MDIO bus but also connects to the main
ethernet interface.  Lots of chips have SPI/I2C control interfaces but
them some other interface for passing data.  A GPIO that enables a
chip but that chip is on a CAN bus interface.

So if you did something like this, you would need some sort of "multiple
inheritance" to cover the corner cases or you would have to live with
the inconsistency.

Device tree, for instance, has a strict hierarchy, but then has ways to
reference the other interfaces that can also control a device.  IIRC
a PHY would sit on the MDIO bus for hierarchy and the ethernet device
has a reference that says "This is my PHY."

-corey

> 
> Emmanuel.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3365 bytes --]