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
| ||
|
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
Powered by blists - more mailing lists