[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AM6PR10MB218134CDB4ECB0A9534B6B96FEE70@AM6PR10MB2181.EURPRD10.PROD.OUTLOOK.COM>
Date: Fri, 21 Jun 2019 09:23:44 +0000
From: Steve Twiss <stwiss.opensource@...semi.com>
To: Wolfram Sang <wsa@...-dreams.de>
CC: "wsa+renesas@...g-engineering.com" <wsa+renesas@...g-engineering.com>,
"bgolaszewski@...libre.com" <bgolaszewski@...libre.com>,
"kieran.bingham+renesas@...asonboard.com"
<kieran.bingham+renesas@...asonboard.com>,
"lee.jones@...aro.org" <lee.jones@...aro.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-renesas-soc@...r.kernel.org"
<linux-renesas-soc@...r.kernel.org>,
"peda@...ntia.se" <peda@...ntia.se>,
Support Opensource <Support.Opensource@...semi.com>
Subject: RE: [PATCH] mfd: da9063: occupy second I2C address, too
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/
Powered by blists - more mailing lists