Hi ChenYu, CC wsa + renesas-soc On Tue, Jan 9, 2024 at 8:08 AM Chen-Yu Tsai <wenst@xxxxxxxxxxxx> wrote: > On Tue, Jan 9, 2024 at 12:09 PM Florian Fainelli <f.fainelli@xxxxxxxxx> wrote: > > 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.). Indeed. E.g. R-Car PCIe just got support for that in commit 6797e4da2dd1e2c8 ("PCI: rcar-host: Add support for optional regulators") in pci/next. > > 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. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
