Re: [PATCH v2 0/2] of: property: fw_devlink misc fixes

[Nicolas Saenz Julienne]

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

Attachment: signature.asc
Description: This is a digitally signed message part