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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 20 Apr 2020 13:29:07 +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

Hi Saravana,

On Fri, 2020-04-17 at 13:55 -0700, Saravana Kannan wrote:
> On Fri, Apr 17, 2020 at 11:06 AM Nicolas Saenz Julienne
> <nsaenzjulienne@...e.de> wrote:
> > Hi Saravana,
> > 
> > On Fri, 2020-04-17 at 18:54 +0200, Nicolas Saenz Julienne wrote:
> > > As I'm interested in using this feature to fine-tune Raspberry Pi 4's
> > > device probe dependencies, I tried to get the board to boot with
> > > fw_devlink=on. As of today's linux-next the board won't boot with that
> > > option. I tried to address the underlying issues.
> > > 
> > 
> > On a semi-related topic, have you looked at vendor specific properties? most
> > of
> > them create a consumer/supplier relationship, it'd be nice to be able to
> > take
> > those ones into account as well.
> 
> I'm on the wall about that. If we take every vendor specific property,
> this file will explode. Not sure I want to do that.
> 
> Also, we haven't even finished all the generic bindings. I'm just
> adding bindings as I get familiar with each of them and I test them on
> hardware I have lying around before sending it out. So, there's where
> my focus is right now wrt fw_devlink and DT.
> 
> I wonder how many of the vendor specific properties do very similar
> things and got in over time. Maybe they can be made generic? What one
> did you have in mind?

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, 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.

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.

Another idea that comes to mind for vendor specific properties would be
exporting a macro in the lines of "DEFINE_SIMPLE_PROP()" for supplier drivers
to define custom properties. The parse_prop() callbacks could then be added
into a special section for of/property.c to pickup and parse. The good thing is
that the list length would be limited by the kernel configuration and the
maintenance burden moved to the driver authors, at least to some extent.

Anyway, if something comes to mind to solve RPi4's situation feel free to
propose anything :).

Regards,
Nicolas

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