linux-kernel - Re: [PATCH v3 0/2] usb: xhci: Load Raspberry Pi 4 VL805's firmware

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 01 Jun 2020 16:41:05 +0200
From:   Nicolas Saenz Julienne <nsaenzjulienne@...e.de>
To:     Marek Vasut <marex@...x.de>, mbrugger@...e.com,
        u-boot@...ts.denx.de, bmeng.cn@...il.com,
        linux-kernel@...r.kernel.org
Cc:     sjg@...omium.org, m.szyprowski@...sung.com, s.nawrocki@...sung.com,
        mark.kettenis@...all.nl
Subject: Re: [PATCH v3 0/2] usb: xhci: Load Raspberry Pi 4 VL805's firmware

On Mon, 2020-06-01 at 13:12 +0200, Marek Vasut wrote:
> On 6/1/20 1:09 PM, Nicolas Saenz Julienne wrote:
> > On Mon, 2020-06-01 at 12:53 +0200, Marek Vasut wrote:
> > > On 6/1/20 12:47 PM, Nicolas Saenz Julienne wrote:
> > > > On Tue, 2020-05-05 at 18:26 +0200, Nicolas Saenz Julienne wrote:
> > > > > Newer revisions of the RPi4 need their xHCI chip, VL805, firmware to
> > > > > be
> > > > > loaded explicitly. Earlier versions didn't need that as they where
> > > > > using
> > > > > an EEPROM for that purpose. This series takes care of setting up the
> > > > > relevant infrastructure and run the firmware loading routine at the
> > > > > right moment.
> > > > > 
> > > > > Note that this builds on top of Sylwester Nawrocki's "USB host support
> > > > > for Raspberry Pi 4 board" series.
> > > > > 
> > > > > ---
> > > > 
> > > > Please don't forget about this series. The new 8GB RPi4 contains this HW
> > > > design
> > > > change and USB will not work without it. See this discussion on the
> > > > downstream
> > > > kernel github, where other OS/bootloaders are hitting the issue:
> > > > 
> > > > https://github.com/raspberrypi/firmware/issues/1402
> > > > 
> > > > Otherwise, the Linux version of this is already in linux-next:
> > > > 
> > > > 
> > 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/usb/host/pci-quirks.c?h=next-20200529&id=c65822fef4adc0ba40c37a47337376ce75f7a7bc
> > > We're already at 2020.07-rc3 , so unless this is a bugfix (does not look
> > > that way), this will have to wait for next release cycle.
> > 
> > Of course. As long as it eventually gets in I'm happy (not implying this
> > specific series is flawless, but the overall mechanism). I'm just worried
> > this
> > gets lost.
> > 
> > > Also, it seems
> > > there was a lengthy ongoing discussion, is that already sorted out ?
> > 
> > Well, there was some discussion on how to incorporate the platform specific
> > callback into XCHI's code. Which this revision of the series addresses. But,
> > IIRC, that's pretty much it as far as discussion is concerned.
> 
> Oh, right, since the firmware loading hook looks like a reset hook, why
> isn't that implemented via reset controller API instead ?

That could be pretty clean, I hadn't though about it that way. Some questions:

- Being a PCIe device the XHCI controller doesn't show up in the device-tree. I
  guess it could be added as a child node of pcie-brcmstb, but is that even
  acceptable?

- Same goes for xhci-pci being a consumer of the reset controller. Given the
  reset scheme is board specific (the chip can be found all over the place, but
  the firmware loading scheme is 100% RPi specific), to what extent we can
  introduce that as a binding?

Regards,
Nicolas


Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)