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  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]
Date:   Mon, 17 Feb 2020 13:40:59 -0800
From:   Florian Fainelli <>
To:     Nicolas Saenz Julienne <>,
        Mathias Nyman <>,
        Ray Jui <>,
        Scott Branden <>,
        Greg Kroah-Hartman <>,,,,
Subject: Re: [PATCH] usb: xhci-pci: Raspberry Pi FW loader for VIA VL805

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

Powered by blists - more mailing lists