On Tue, Jan 9, 2024 at 12:09 PM Florian Fainelli <f.fainelli@xxxxxxxxx> wrote: > > Hello, > > On 1/4/2024 5:01 AM, Bartosz Golaszewski wrote: > > From: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx> > > > > During last year's Linux Plumbers we had several discussions centered > > around the need to power-on PCI devices before they can be detected on > > the bus. > > > > The consensus during the conference was that we need to introduce a > > class of "PCI slot drivers" that would handle the power-sequencing. > > > > After some additional brain-storming with Manivannan and the realization > > that the DT maintainers won't like adding any "fake" nodes not > > representing actual devices, we decided to reuse the existing > > infrastructure provided by the PCIe port drivers. > > > > The general idea is to instantiate platform devices for child nodes of > > the PCIe port DT node. For those nodes for which a power-sequencing > > driver exists, we bind it and let it probe. The driver then triggers a > > rescan of the PCI bus with the aim of detecting the now powered-on > > device. The device will consume the same DT node as the platform, > > power-sequencing device. We use device links to make the latter become > > the parent of the former. > > > > The main advantage of this approach is not modifying the existing DT in > > any way and especially not adding any "fake" platform devices. > > There is prior work in that area which was applied, but eventually reverted: > > https://www.spinics.net/lists/linux-pci/msg119136.html > > and finally re-applied albeit in a different shape: > > https://lore.kernel.org/all/20220716222454.29914-1-jim2101024@xxxxxxxxx/ > > so we might want to think about how to have pcie-brcmstb.c converted > over your proposed approach. AFAIR there is also pcie-rockchip.c which > has some rudimentary support for voltage regulators of PCIe end-points. I think the current in-tree approaches mostly target either PCIe slots, whether full size or mini-PCIe or M.2, or soldered-on components that either only have a single power rail, have internal regulators, or have surrounding circuitry that would be incorporated on a PCIe card. These all have standardized power rails (+12V, +3.3V, +3.3V aux, etc.). > What does not yet appear in this RFC is support for suspend/resume, > especially for power states where both the RC and the EP might be losing > power. There also needs to be some thoughts given to wake-up enabled > PCIe devices like Wi-Fi which might need to remain powered on to service > Wake-on-WLAN frames if nothing else. > > I sense a potential for a lot of custom power sequencing drivers being > added and ultimately leading to the decision to create a "generic" one > which is entirely driven by Device Tree properties... We can have one "generic" slot power sequencing driver, which just enables all the power rails together. I would very much like to see that. I believe the power sequencing in this series is currently targeting more tightly coupled designs that use power rails directly from the PMIC, and thus require more explicit power sequencing. ChenYu > Thanks for doing this! > -- > Florian > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
