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.
Emmanuel.
