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
