* Re: [PATCH] mfd: da9063: occupy second I2C address, too
@ 2019-06-20 9:07 Steve Twiss
2019-06-20 9:21 ` Wolfram Sang
2019-06-20 12:28 ` Lee Jones
0 siblings, 2 replies; 9+ messages in thread
From: Steve Twiss @ 2019-06-20 9:07 UTC (permalink / raw)
To: wsa+renesas
Cc: bgolaszewski, kieran.bingham+renesas, lee.jones, linux-kernel,
linux-renesas-soc, peda, Support Opensource
(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 <wsa+renesas@sang-engineering.com>
> Reviewed-by: Peter Rosin <peda@axentia.se>
> Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
> ---
> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] mfd: da9063: occupy second I2C address, too
2019-06-20 9:07 [PATCH] mfd: da9063: occupy second I2C address, too Steve Twiss
@ 2019-06-20 9:21 ` Wolfram Sang
2019-06-21 9:23 ` Steve Twiss
2019-06-20 12:28 ` Lee Jones
1 sibling, 1 reply; 9+ messages in thread
From: Wolfram Sang @ 2019-06-20 9:21 UTC (permalink / raw)
To: Steve Twiss
Cc: wsa+renesas, bgolaszewski, kieran.bingham+renesas, lee.jones,
linux-kernel, linux-renesas-soc, peda, Support Opensource
[-- Attachment #1: Type: text/plain, Size: 280 bytes --]
> 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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] mfd: da9063: occupy second I2C address, too
2019-06-20 9:07 [PATCH] mfd: da9063: occupy second I2C address, too Steve Twiss
2019-06-20 9:21 ` Wolfram Sang
@ 2019-06-20 12:28 ` Lee Jones
2019-06-20 12:44 ` Steve Twiss
1 sibling, 1 reply; 9+ messages in thread
From: Lee Jones @ 2019-06-20 12:28 UTC (permalink / raw)
To: Steve Twiss
Cc: wsa+renesas, bgolaszewski, kieran.bingham+renesas, linux-kernel,
linux-renesas-soc, peda, Support Opensource
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 <wsa+renesas@sang-engineering.com>
> > Reviewed-by: Peter Rosin <peda@axentia.se>
> > Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> > Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
> > ---
> > 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: [PATCH] mfd: da9063: occupy second I2C address, too
2019-06-20 12:28 ` Lee Jones
@ 2019-06-20 12:44 ` Steve Twiss
2019-06-20 13:33 ` Lee Jones
0 siblings, 1 reply; 9+ messages in thread
From: Steve Twiss @ 2019-06-20 12:44 UTC (permalink / raw)
To: Lee Jones, wsa+renesas
Cc: bgolaszewski, kieran.bingham+renesas, linux-kernel,
linux-renesas-soc, peda, Support Opensource
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] mfd: da9063: occupy second I2C address, too
2019-06-20 12:44 ` Steve Twiss
@ 2019-06-20 13:33 ` Lee Jones
0 siblings, 0 replies; 9+ messages in thread
From: Lee Jones @ 2019-06-20 13:33 UTC (permalink / raw)
To: Steve Twiss
Cc: wsa+renesas, bgolaszewski, kieran.bingham+renesas, linux-kernel,
linux-renesas-soc, peda, Support Opensource
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: [PATCH] mfd: da9063: occupy second I2C address, too
2019-06-20 9:21 ` Wolfram Sang
@ 2019-06-21 9:23 ` Steve Twiss
2019-06-21 10:09 ` Wolfram Sang
0 siblings, 1 reply; 9+ messages in thread
From: Steve Twiss @ 2019-06-21 9:23 UTC (permalink / raw)
To: Wolfram Sang
Cc: wsa+renesas, bgolaszewski, kieran.bingham+renesas, lee.jones,
linux-kernel, linux-renesas-soc, peda, Support Opensource
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/20190619171806.30116-1-wsa+renesas@sang-engineering.com/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] mfd: da9063: occupy second I2C address, too
2019-06-21 9:23 ` Steve Twiss
@ 2019-06-21 10:09 ` Wolfram Sang
2019-06-21 10:23 ` Steve Twiss
0 siblings, 1 reply; 9+ messages in thread
From: Wolfram Sang @ 2019-06-21 10:09 UTC (permalink / raw)
To: Steve Twiss
Cc: wsa+renesas, bgolaszewski, kieran.bingham+renesas, lee.jones,
linux-kernel, linux-renesas-soc, peda, Support Opensource
[-- Attachment #1: Type: text/plain, Size: 325 bytes --]
> 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...
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: [PATCH] mfd: da9063: occupy second I2C address, too
2019-06-21 10:09 ` Wolfram Sang
@ 2019-06-21 10:23 ` Steve Twiss
0 siblings, 0 replies; 9+ messages in thread
From: Steve Twiss @ 2019-06-21 10:23 UTC (permalink / raw)
To: Wolfram Sang
Cc: wsa+renesas, bgolaszewski, kieran.bingham+renesas, lee.jones,
linux-kernel, linux-renesas-soc, peda, Support Opensource
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] mfd: da9063: occupy second I2C address, too
@ 2019-06-19 17:18 Wolfram Sang
0 siblings, 0 replies; 9+ messages in thread
From: Wolfram Sang @ 2019-06-19 17:18 UTC (permalink / raw)
To: linux-kernel
Cc: Lee Jones, linux-renesas-soc, Wolfram Sang, Peter Rosin,
Bartosz Golaszewski, Kieran Bingham
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 <wsa+renesas@sang-engineering.com>
Reviewed-by: Peter Rosin <peda@axentia.se>
Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
---
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
^ permalink raw reply related [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-06-21 10:23 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-20 9:07 [PATCH] mfd: da9063: occupy second I2C address, too Steve Twiss
2019-06-20 9:21 ` Wolfram Sang
2019-06-21 9:23 ` Steve Twiss
2019-06-21 10:09 ` Wolfram Sang
2019-06-21 10:23 ` Steve Twiss
2019-06-20 12:28 ` Lee Jones
2019-06-20 12:44 ` Steve Twiss
2019-06-20 13:33 ` Lee Jones
-- strict thread matches above, loose matches on Subject: below --
2019-06-19 17:18 Wolfram Sang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).