On Thu, 20 Jun 2019, Steve Twiss wrote: > (resend because the e-mail client added HTML formatting to my last reply) > > Hi Wolfram, > > On Wed, 19 Jun 2019 19:18:06, Wolfram Sang wrote: > > > Subject: [PATCH] mfd: da9063: occupy second I2C address, too > > > > Even though we don't use it yet, we should mark the second I2C address > > this device is listening to as used. > > Sure. There is a second method for accessing higher pages of registers. > The DA9063 Datasheet Revision 2.2, 12-Mar-2019, page 96, says this: > > In 2-WIRE operation, the DA9063 offers an alternative method to access > register pages 2 and 3. > These pages can be accessed directly by incrementing the device address by > one (default read > address 0xB3; write address 0xB2). This removes the need to write to the page > register before > access to pages 2 and 3, thus reducing the traffic on the 2-WIRE bus. > > Is this a safety clause? What I mean is, shouldn't the hardware design make > sure there are not two devices located on the same I2C bus with the same slave > address?
Why isn't this reply attached (threaded) to the patch. Is your mailer broken? > > Signed-off-by: Wolfram Sang <[email protected]> > > Reviewed-by: Peter Rosin <[email protected]> > > Reviewed-by: Bartosz Golaszewski <[email protected]> > > Reviewed-by: Kieran Bingham <[email protected]> > > --- > > drivers/mfd/da9063-i2c.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/mfd/da9063-i2c.c b/drivers/mfd/da9063-i2c.c > > index 455de74c0dd2..2133b09f6e7a 100644 > > --- a/drivers/mfd/da9063-i2c.c > > +++ b/drivers/mfd/da9063-i2c.c > > @@ -221,6 +221,8 @@ static int da9063_i2c_probe(struct i2c_client *i2c, > > return ret; > > } > > > > + devm_i2c_new_dummy_device(&i2c->dev, i2c->adapter, i2c->addr + 1); > > + > > return da9063_device_init(da9063, i2c->irq); > > } > > > -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
