Re: [PATCH RFC v3 1/8] of: Mark interconnects property supplier as optional

From: Maxime Ripard <maxime@cerno.tech>
To: Saravana Kannan <saravanak@google.com>
Cc: Rob Herring <robh@kernel.org>,
	Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org,
	linux-media@vger.kernel.org, Chen-Yu Tsai <wens@csie.org>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Samuel Holland <samuel@sholland.org>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH RFC v3 1/8] of: Mark interconnects property supplier as optional
Date: Wed, 27 Jul 2022 14:06:31 +0200	[thread overview]
Message-ID: <20220727120631.iefzititedahdsdt@houat> (raw)
In-Reply-To: <CAGETcx9u9RO_5nSp+=qgwDGY=jL_Q1hAcj+RfVN=q-H_8iuT4w@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2235 bytes --]

Hi,

On Mon, Mar 07, 2022 at 07:34:22PM -0800, Saravana Kannan wrote:
> On Mon, Mar 7, 2022 at 3:21 PM Rob Herring <robh@kernel.org> wrote:
> >
> > +Saravana
> >
> > On Wed, Mar 02, 2022 at 10:10:53PM +0100, Paul Kocialkowski wrote:
> > > In order to set their correct DMA address offset, some devices rely on
> > > the device-tree interconnects property which identifies an
> > > interconnect node that provides a dma-ranges property that can be used
> > > to set said offset.
> > >
> > > Since that logic is all handled by the generic openfirmware and driver
> > > code, the device-tree description could be enough to properly set
> > > the offset.
> > >
> > > However the interconnects property is currently not marked as
> > > optional, which implies that a driver for the corresponding node
> > > must be loaded as a requirement. When no such driver exists, this
> > > results in an endless EPROBE_DEFER which gets propagated to the
> > > calling driver. This ends up in the driver never loading.
> > >
> > > Marking the interconnects property as optional makes it possible
> > > to load the driver in that situation, since the EPROBE_DEFER return
> > > code will no longer be propagated to the driver.
> > >
> > > There might however be undesirable consequences with this change,
> > > which I do not fully grasp at this point.
> 
> Temporary NACK till I get a bit more time to take a closer look. I
> really don't like the idea of making interconnects optional. IOMMUs
> and DMAs were exceptions. Also, we kinda discuss similar issues in
> LPC. We had some consensus on how to handle these and I noted them all
> down with a lot of details -- let me go take a look at those notes
> again and see if I can send a more generic patch.
> 
> Paul,
> 
> Can you point to the DTS (not DTSI) file that corresponds to this?
> Also, if it's a builtin kernel, I'd recommend setting
> deferred_probe_timeout=1 and that should take care of it too.

For the record, I also encountered this today on next-20220726 with this
device:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/sun5i.dtsi#n775

The driver won't probe without fw_devlink=off

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]