linux-kernel - Re: [PATCH] usb: xhci-pci: Raspberry Pi FW loader for VIA VL805

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 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 <f.fainelli@...il.com>
To:     Nicolas Saenz Julienne <nsaenzjulienne@...e.de>,
        Mathias Nyman <mathias.nyman@...el.com>,
        Ray Jui <rjui@...adcom.com>,
        Scott Branden <sbranden@...adcom.com>,
        bcm-kernel-feedback-list@...adcom.com
Cc:     oneukum@...e.com, phil@...pberrypi.com, tim.gover@...pberrypi.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-rpi-kernel@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org
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 <nsaenzjulienne@...e.de>
>>
>> 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