Even though we don't use it yet, we should mark the second I2C address
this device is listening to as used.
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);
}
--
2.20.1
(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?
Regards,
Steve
> 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);
> }
>
> --
> 2.20.1
> 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?
It is more about preventing userspace to accidently access this address,
and thus the registers behind it.
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
On 20 June 2019 13:29, Lee Jones wrote:
> Subject: Re: [PATCH] mfd: da9063: occupy second I2C address, too
>
> Why isn't this reply attached (threaded) to the patch.
My apologies. It wasn't my intention to split Wolfram's original e-mail thread.
I don't usually reply using the mailto: link from lore when creating e-mails.
Outlook mustn't support the In-Reply-To header.
I'll figure out a different way to reply in future.
> Is your mailer broken?
It's Windows
On Thu, 20 Jun 2019, Steve Twiss wrote:
> On 20 June 2019 13:29, Lee Jones wrote:
>
> > Subject: Re: [PATCH] mfd: da9063: occupy second I2C address, too
> >
> > Why isn't this reply attached (threaded) to the patch.
>
> My apologies. It wasn't my intention to split Wolfram's original e-mail thread.
>
> I don't usually reply using the mailto: link from lore when creating e-mails.
> Outlook mustn't support the In-Reply-To header.
>
> I'll figure out a different way to reply in future.
>
> > Is your mailer broken?
>
> It's Windows
Say no more. ;)
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Hi Wolfram,
On 20 June 2019 10:21, Wolfram Sang wrote:
> Subject: Re: [PATCH] mfd: da9063: occupy second I2C address, too
>
> > 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?
>
> It is more about preventing userspace to accidently access this address,
> and thus the registers behind it.
For what it's worth, maybe consider adding a dev_warn attached to the return
of devm_i2c_new_dummy_device?
Regards,
Steve
My apologies again for accidentally splitting your original e-mail thread on this:
- https://lore.kernel.org/lkml/[email protected]/
> For what it's worth, maybe consider adding a dev_warn attached to the return
> of devm_i2c_new_dummy_device?
I am in the middle of some API changes. Once those are over, I want to
think about such warnings as a second step. I'd rather have them in the
core than in each and every driver. But this needs more thinking...
On 21 June 2019 11:10 Wolfram Sang wrote:
> Subject: Re: [PATCH] mfd: da9063: occupy second I2C address, too
>
> > For what it's worth, maybe consider adding a dev_warn attached to the return
> > of devm_i2c_new_dummy_device?
>
> I am in the middle of some API changes. Once those are over, I want to
> think about such warnings as a second step. I'd rather have them in the
> core than in each and every driver. But this needs more thinking...
No problem.