Re: [RFC PATCH 3/5] i2c: core: add function to request an alias

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: Luca Ceresoli <luca@lucaceresoli.net>,
	Wolfram Sang <wsa+renesas@sang-engineering.com>,
	linux-i2c@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
	Kieran Bingham <kieran@ksquared.org.uk>,
	Jacopo Mondi <jacopo@jmondi.org>,
	Vladimir Zapolskiy <vz@mleia.com>
Subject: Re: [RFC PATCH 3/5] i2c: core: add function to request an alias
Date: Wed, 8 Jan 2020 15:34:47 +0200	[thread overview]
Message-ID: <20200108133447.GC4884@pendragon.ideasonboard.com> (raw)
In-Reply-To: <20200108131929.GA834@kunai>

On Wed, Jan 08, 2020 at 02:19:29PM +0100, Wolfram Sang wrote:
> 
> > > > As I said to Laurent, too, I think the risk that a bus is not fully
> > > > described is higher than a device which does not respond to a read_byte.
> > > > In both cases, we would wrongly use an address in use.
> > 
> > I don't fully agree with this, I think we shouldn't impose a penalty on
> > every user because some device trees don't fully describe the hardware.
> 
> I haven't decided yet. However, my general preference is that for a
> generic OS like Linux, saftey comes first, then performance. If you have
> a fully described DT, then the overhead will be 1 read_byte transaction
> per requested alias at probe time. We could talk about using quick_read
> to half the overhead. You could even patch it away, if it is too much
> for $customer.
> 
> > I think we should, at the very least, skip the probe and rely on DT if
> > DT explicitly states that all used addresses are listed. We discussed a
> > property to report addresses used by devices not described in DT, if
> > that property is listed I would prefer trusting DT.
> 
> Yeah, we discussed this property and I have no intentions of dropping
> it. I haven't though of including it into this series, but it probably
> makes sense. We don't have to define much anyhow, just state what
> already exists, I guess.
> 
> From Documentation/devicetree/bindings/i2c/i2c-ocores.txt:
> 
> 	dummy@60 {
> 		compatible = "dummy";
> 		reg = <0x60>;
> 	};
> 
> I think "dummy" is generic enough to be described in i2c.txt.

We may want a compatible value that guarantees noone will ever match it
:-) I was imagining a single property at the bus level with multiple
ranges instead, but dummy nodes could be OK too.

-- 
Regards,

Laurent Pinchart