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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGETcx_o=L+Ku9CPGbQW2wS15etvi+ofkKZ0K=C7imP4=JcXeQ@mail.gmail.com>
Date:   Wed, 27 Jul 2022 09:06:15 -0700
From:   Saravana Kannan <saravanak@...gle.com>
To:     Maxime Ripard <maxime@...no.tech>
Cc:     Rob Herring <robh@...nel.org>,
        Paul Kocialkowski <paul.kocialkowski@...tlin.com>,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-sunxi@...ts.linux.dev, linux-kernel@...r.kernel.org,
        linux-media@...r.kernel.org, Chen-Yu Tsai <wens@...e.org>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        Samuel Holland <samuel@...lland.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Frank Rowand <frowand.list@...il.com>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH RFC v3 1/8] of: Mark interconnects property supplier as optional

On Wed, Jul 27, 2022 at 5:06 AM Maxime Ripard <maxime@...no.tech> wrote:
>
> 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@...nel.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

Really? I basically ended up doing what I mentioned in my original
reply. next-20220726 should have my changes that'll make sure
fw_devlink doesn't block any probe (it'll still try to create as many
device links as possible) after 10s (default deferred probe timeout).
Can you try to find more info on why it's not probing?
<debugfs>/devices_deferred should give more details.


-Saravana