[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <AM6PR10MB218113C2BA3940643CBFEAABFEE70@AM6PR10MB2181.EURPRD10.PROD.OUTLOOK.COM>
Date: Fri, 21 Jun 2019 10:23:26 +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
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.
Powered by blists - more mailing lists