linux-kernel - Re: [PATCH v2 0/3] Make fw

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]

Date:   Tue, 2 Feb 2021 10:28:11 -0800
From:   Saravana Kannan <saravanak@...gle.com>
To:     Rob Herring <robh+dt@...nel.org>
Cc:     Tudor Ambarus <Tudor.Ambarus@...rochip.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Marc Zyngier <maz@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Martin Kaiser <martin@...ser.cx>,
        Frank Rowand <frowand.list@...il.com>,
        Len Brown <lenb@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        "open list:ACPI FOR ARM64 (ACPI/arm64)" <linux-acpi@...r.kernel.org>,
        Android Kernel Team <kernel-team@...roid.com>
Subject: Re: [PATCH v2 0/3] Make fw_devlink=on more forgiving

On Tue, Feb 2, 2021 at 9:41 AM Rob Herring <robh+dt@...nel.org> wrote:
>
> On Tue, Feb 2, 2021 at 10:52 AM <Tudor.Ambarus@...rochip.com> wrote:
> >
> > Hi, Saravana,
> >
> > On 2/2/21 6:33 AM, Saravana Kannan wrote:
> > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > >
> > > This patch series solves two general issues with fw_devlink=on
> > >
> > > Patch 1/3 and 3/3 addresses the issue of firmware nodes that look like
> > > they'll have struct devices created for them, but will never actually
> > > have struct devices added for them. For example, DT nodes with a
> > > compatible property that don't have devices added for them.
> > >
> > > Patch 2/2 address (for static kernels) the issue of optional suppliers
> > > that'll never have a driver registered for them. So, if the device could
> > > have probed with fw_devlink=permissive with a static kernel, this patch
> > > should allow those devices to probe with a fw_devlink=on. This doesn't
> > > solve it for the case where modules are enabled because there's no way
> > > to tell if a driver will never be registered or it's just about to be
> > > registered. I have some other ideas for that, but it'll have to come
> > > later thinking about it a bit.
> > >
> > > Marek, Geert,
> > >
> > > I don't expect v2 to do any better for your cases.
> > >
> > > This series not making any difference for Marek is still a mystery to
> > > me. I guess one of the consumers doesn't take too well to its probe (and
> > > it's consumers' probe) being delayed till late_initcall(). I'll continue
> > > looking into it.
> > >
> > > Marc,
> > >
> > > This v2 should do better than v1 with gpiolib stub driver reverted. I
> > > forgot to take care of the case where more suppliers could link after I
> > > went and deleted some of the links. v2 handles that now.
> > >
> > > Tudor,
> > >
> > > You should still make the clock driver fix (because it's a bug), but I
> > > think this series will fix your issue too (even without the clock driver
> > > fix). Can you please give this a shot?
> > >
> >
> > Did the following tests (using sama5_defconfig and at91-sama5d2_xplained.dts):
> > 1/ modular kernel with your v2 on top of next-20210202, and without the clock
> > driver fix: the problem persists.
> >
> > 2/ static kernel with your v2 on top of next-20210202, and without the clock
> > driver fix: the problem persists. Comparing to the previous test, I see that
> > the links to pmc are dropped. I can see the following only with early printk
> > enabled:
> > platform fc008000.serial: Dropping the link to f0014000.pmc
> > But later on, the serial still gets deferred waiting for the dma controller
> > this time:
> > platform f8020000.serial: probe deferral - supplier f0010000.dma-controller not ready
> > I'll check what happens in the dma-controller.
>
> Not sure if it's the case here, but some serial drivers use DMA only
> when available and decide that on open() rather than probe. How is
> devlinks going to deal with that?

That's kinda what I'm trying to work out here :) but in a more generic fashion.

-Saravana