On 2 December 2016 at 05:46, Alastair D'Silva <alast...@au1.ibm.com> wrote: > From: Alastair D'Silva <alast...@d-silva.org> > > The imx25 chip provides 3 i2c buses, but they have all been named > "i2c", which makes it difficult to predict which bus a device will > be connected to when specified on the command line. > > This patch addresses the issue by naming the buses uniquely: > i2c-bus.0 i2c-bus.1 i2c-bus.2 > > Signed-off-by: Alastair D'Silva <alast...@d-silva.org> > --- > hw/arm/imx25_pdk.c | 4 +--- > hw/i2c/imx_i2c.c | 2 +- > 2 files changed, 2 insertions(+), 4 deletions(-) > > diff --git a/hw/arm/imx25_pdk.c b/hw/arm/imx25_pdk.c > index 025b608..c6f04d3 100644 > --- a/hw/arm/imx25_pdk.c > +++ b/hw/arm/imx25_pdk.c > @@ -138,9 +138,7 @@ static void imx25_pdk_init(MachineState *machine) > * We add it here (only on qtest usage) to be able to do a bit > * of simple qtest. See "make check" for details. > */ > - i2c_create_slave((I2CBus *)qdev_get_child_bus(DEVICE(&s->soc.i2c[0]), > - "i2c"), > - "ds1338", 0x68); > + i2c_create_slave(s->soc.i2c[0].bus, "ds1338", 0x68);
This bit doesn't look right. The board level code shouldn't be poking around inside the IMXI2CState struct, as that is private to the device implementation. That's why we're calling qdev_get_child_bus(). > } > } thanks -- PMM