linux-kernel - Re: [PATCH v2 0/2] of: property: 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] [day] [month] [year] [list]

Message-ID: <3f46cb2631eddda754660586942e31ece27a7f00.camel@suse.de>
Date:   Tue, 21 Apr 2020 10:54:55 +0200
From:   Nicolas Saenz Julienne <nsaenzjulienne@...e.de>
To:     Saravana Kannan <saravanak@...gle.com>
Cc:     Frank Rowand <frowand.list@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 0/2] of: property: fw_devlink misc fixes

On Mon, 2020-04-20 at 15:37 -0700, Saravana Kannan wrote:

[...]

> On Mon, Apr 20, 2020 at 4:29 AM Nicolas Saenz Julienne
> > Well, long story short, we need to create a relationship between RPi4's PCI
> > bus
> > (which hangs from an interconnect in DT) and RPi4's co-processor, which has
> > a
> > highly unconventional firmware driver (raspberrypi.c in drivers/firmware).
> > The
> > PCI bus just needs the co-processor interface to be up before probing,
> 
> I'm guessing it still works fine today by doing a deferred probe and
> you are just trying to avoid having to do a deferred probe? I haven't
> kept track of RPi4's upstream support status.

Yes that's the idea, and here's the patch I'm trying to avoid:
https://lkml.org/lkml/2020/3/24/1508

> > that's
> > all (I'll spare you the details of why). Ideally we want to avoid adding
> > platform specific code into an otherwise generic bus driver as it'll be used
> > by
> > a number of unrelated SoCs, and it's generally frowned upon.
> 
> Which PCI driver is that specifically (I'm sure I can dig around to
> find RPi4's DT and figure it out, but it's easier to just ask :) ) ?
> Also, can you point me to the DT and the nodes that we are talking
> about here (the PCI and the firmware nodes)?

So the PCI driver is pcie-brcmstb.c, its DT node is available in bcm2711.dtsi
(search for pcie0), the firmware interface is defined in bcm2835-rpi.dtsi
(search for firmware).

> > There is no generic property to handle this case, and it's very unlikely
> > there
> > will ever be one, since these firmware drivers have very little in common. I
> > guess this could make an argument for a generic _last resort only_
> > 'supplied-by' property, but I bet this solution won't be very popular.
> 
> Ha, this was my initial idea for the whole fw_devlink feature. I
> called it depends-on. Rob/Frank convinced me to instead just parse the
> existing bindings -- which was definitely the right call. Otherwise DT
> would have been a mess. Adding support for "depends-on" for one off
> use cases might still be a touchy topic. I myself am on the wall. It's
> useful for some rare cases, but it's also very easy to abuse.

Yes, I agree.

Regards,
Nicolas


Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)