On 12/14/2016 06:41 PM, Peter Maydell wrote: > 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().
That was my suggestion. Sorry about that. May be, we could use "i2c.0", now that we have numbered the I2C bus names ? Thanks, C.
