Re: [PATCH] mfd: da9063: occupy second I2C address, too

Re: [PATCH] mfd: da9063: occupy second I2C address, too

[Steve Twiss]

(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

Re: [PATCH] mfd: da9063: occupy second I2C address, too

[Wolfram Sang]

[-- 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 --]

RE: [PATCH] mfd: da9063: occupy second I2C address, too

[Steve Twiss]

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/

Re: [PATCH] mfd: da9063: occupy second I2C address, too

[Wolfram Sang]

[-- 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 --]

RE: [PATCH] mfd: da9063: occupy second I2C address, too

[Steve Twiss]

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. 

Re: [PATCH] mfd: da9063: occupy second I2C address, too

[Lee Jones]

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

RE: [PATCH] mfd: da9063: occupy second I2C address, too

[Steve Twiss]

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

Re: [PATCH] mfd: da9063: occupy second I2C address, too

[Lee Jones]

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

[PATCH] mfd: da9063: occupy second I2C address, too

[Wolfram Sang]

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>
---

This patch could not be applied 6 years ago because of a missing
dependency. It has arrived meanwhile ;)

 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 c6235cd0dbdc..c74702cf8a77 100644
--- a/drivers/mfd/da9063-i2c.c
+++ b/drivers/mfd/da9063-i2c.c
@@ -454,6 +454,8 @@ static int da9063_i2c_probe(struct i2c_client *i2c)
 		}
 	}
 
+	devm_i2c_new_dummy_device(&i2c->dev, i2c->adapter, i2c->addr + 1);
+
 	return da9063_device_init(da9063, i2c->irq);
 }
 
-- 
2.47.2

Re: [PATCH] mfd: da9063: occupy second I2C address, too

[Lee Jones]

On Sun, 01 Jun 2025, Wolfram Sang wrote:

> Even though we don't use it yet, we should mark the second I2C address
> this device is listening to as used.

Could we have a bit more information please?

What happens if we don't do this?

> 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>
> ---
> 
> This patch could not be applied 6 years ago because of a missing
> dependency. It has arrived meanwhile ;)
> 
>  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 c6235cd0dbdc..c74702cf8a77 100644
> --- a/drivers/mfd/da9063-i2c.c
> +++ b/drivers/mfd/da9063-i2c.c
> @@ -454,6 +454,8 @@ static int da9063_i2c_probe(struct i2c_client *i2c)
>  		}
>  	}

Maybe a comment for future readers wondering why we're obtaining this
unused I2C address.  It may prevent others from removing it as
superfluous.

> +	devm_i2c_new_dummy_device(&i2c->dev, i2c->adapter, i2c->addr + 1);
> +
>  	return da9063_device_init(da9063, i2c->irq);
>  }
>  
> -- 
> 2.47.2
> 

-- 
Lee Jones [李琼斯]

Re: [PATCH] mfd: da9063: occupy second I2C address, too

[Lee Jones]

On Fri, 13 Jun 2025, Lee Jones wrote:

> On Sun, 01 Jun 2025, Wolfram Sang wrote:
> 
> > Even though we don't use it yet, we should mark the second I2C address
> > this device is listening to as used.
> 
> Could we have a bit more information please?
> 
> What happens if we don't do this?
> 
> > 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>
> > ---
> > 
> > This patch could not be applied 6 years ago because of a missing
> > dependency. It has arrived meanwhile ;)

Link to dep for ease of review (and for the nosey).  =:-)

> >  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 c6235cd0dbdc..c74702cf8a77 100644
> > --- a/drivers/mfd/da9063-i2c.c
> > +++ b/drivers/mfd/da9063-i2c.c
> > @@ -454,6 +454,8 @@ static int da9063_i2c_probe(struct i2c_client *i2c)
> >  		}
> >  	}
> 
> Maybe a comment for future readers wondering why we're obtaining this
> unused I2C address.  It may prevent others from removing it as
> superfluous.
> 
> > +	devm_i2c_new_dummy_device(&i2c->dev, i2c->adapter, i2c->addr + 1);
> > +
> >  	return da9063_device_init(da9063, i2c->irq);
> >  }
> >  
> > -- 
> > 2.47.2
> > 
> 
> -- 
> Lee Jones [李琼斯]

-- 
Lee Jones [李琼斯]

[PATCH] mfd: da9063: occupy second I2C address, too

[Wolfram Sang]

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