On 2/17/2020 1:19 PM, Nicolas Saenz Julienne wrote: > On Mon, 2020-02-17 at 12:52 -0800, Florian Fainelli wrote: >> >> On 2/17/2020 2:07 AM, Nicolas Saenz Julienne wrote: >>> On the Raspberry Pi 4, after a PCI reset, VL805's firmware may either be >>> loaded directly from an EEPROM or, if not present, by the SoC's >>> VideCore. Inform VideCore that VL805 was just reset, or defer xhci's >>> probe if not yet joinable trough the mailbox interface. >>> >>> Based on Tim Gover's downstream implementation. >>> >>> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@xxxxxxx> >> >> Would it work if you registered the firmware loading as pci fixup such >> that you would not even have to mangle xhci-pci.c at all and all the >> logic could be contained within drivers/firmware/raspberrypi.c? > > Not that simple, PCI fix-ups don't allow for probe deferring. We depend on the > firmware and mailbox drivers to be up prior running this, so it's essential. We > could cheat and do the deferring first thing during pcie-brcmstb's probe. > > Actually this might be a workable solution (as in upstreamable): > - Wait for firmware to be up in pcie-brcmstb.c > - Add firmware code in firmware/raspberrypi.c > - Perform call in usb's quirk_usb_early_handoff() (usb/host/pci-quirks.c) Humm, not a big fan of having to have pcie-brcmstb.c become aware of a firmware loader, because this does not scale great over PCIe root complex controller drivers for one and this is such a Pi4 (not even 2711) specialism that it feels a bit too much... might as well go with your existing patch, just address Greg's feedback? Or how about introducing a type of fixup that could trigger a probe deferral? -- Florian
