On Fri, 2020-08-14 at 08:11 +0200, Greg KH wrote:

On Thu, Aug 13, 2020 at 12:17:49PM -0700, Florian Fainelli wrote:

quoted

On 8/13/2020 3:01 AM, Nicolas Saenz Julienne wrote:

quoted

Hi everyone.

On Mon, 2020-06-29 at 18:18 +0200, Nicolas Saenz Julienne wrote:

quoted

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
co-processor, VideoCore. This series reworks how we handle this.

The previous solution makes use of PCI quirks and exporting platform
specific functions. Albeit functional it feels pretty shoehorned. This
proposes an alternative way of handling the triggering of the xHCI chip
initialization trough means of a reset controller.

The benefits are pretty evident: less platform churn in core xHCI code,
and no explicit device dependency management in pcie-brcmstb.

Note that patch #1 depends on another series[1], that was just applied
into the clk maintainer's tree.

The series is based on v5.8-rc3

v3: https://www.spinics.net/lists/arm-kernel/msg813612.html
v2: https://lkml.org/lkml/2020/6/9/875
v1: https://lore.kernel.org/linux-usb/20200608192701.18355-1-nsaenzjulienne@suse.de/T/#t (local)

[1] https://lore.kernel.org/linux-clk/159304773261.62212.983376627029743900@swboyd.mtv.corp.google.com/T/#t (local)

---

We were waiting on a dependency to be merged upstream to get this. They are now
in, so could we move things forward?

I can take the device tree patches, I guess philipp can take the reset
controller code. But I'm not so sure who should be taking the PCI/USB
counterparts.

Should we route everything through the USB tree since that is where the
changes that do require synchronization with other subsystems and DTS is
needed the most?
-- 
Florian

That's fine with me, if everyone else is ok with it :)

Sounds good to me.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel