From: Bartosz Golaszewski <[email protected]>
The responses to the RFC were rather positive so here's a proper series.
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 DT maintainers won't like adding any "fake" nodes not representing
actual devices, we decided to reuse existing PCI infrastructure.
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.
Changes since RFC:
- move the pwrseq functionality out of the port driver and into PCI core
- add support for WCN7850 to the first pwrseq driver (and update bindings)
- describe the WLAN modules in sm8550-qrd and sm8650-qrd
- rework Kconfig options, drop the defconfig changes from the series as
they are no longer needed
- drop the dt-binding changes for PCI vendor codes
- extend the DT bindings for ath11k_pci with strict property checking
- various minor tweaks and fixes
Bartosz Golaszewski (7):
arm64: dts: qcom: qrb5165-rb5: describe the WLAN module of QCA6390
PCI: create platform devices for child OF nodes of the port node
PCI: hold the rescan mutex when scanning for the first time
PCI/pwrseq: add pwrseq core code
dt-bindings: wireless: ath11k: describe QCA6390
dt-bindings: wireless: ath11k: describe WCN7850
PCI/pwrseq: add a pwrseq driver for QCA6390
Neil Armstrong (2):
arm64: dts: qcom: sm8550-qrd: add Wifi nodes
arm64: dts: qcom: sm8650-qrd: add Wifi nodes
.../net/wireless/qcom,ath11k-pci.yaml | 89 ++++++
arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 29 ++
arch/arm64/boot/dts/qcom/sm8250.dtsi | 10 +
arch/arm64/boot/dts/qcom/sm8550-qrd.dts | 37 +++
arch/arm64/boot/dts/qcom/sm8550.dtsi | 10 +
arch/arm64/boot/dts/qcom/sm8650-qrd.dts | 29 ++
arch/arm64/boot/dts/qcom/sm8650.dtsi | 10 +
drivers/pci/Kconfig | 1 +
drivers/pci/Makefile | 1 +
drivers/pci/bus.c | 9 +-
drivers/pci/probe.c | 2 +
drivers/pci/pwrseq/Kconfig | 16 ++
drivers/pci/pwrseq/Makefile | 4 +
drivers/pci/pwrseq/pci-pwrseq-qca6390.c | 267 ++++++++++++++++++
drivers/pci/pwrseq/pwrseq.c | 82 ++++++
drivers/pci/remove.c | 3 +-
include/linux/pci-pwrseq.h | 24 ++
17 files changed, 621 insertions(+), 2 deletions(-)
create mode 100644 drivers/pci/pwrseq/Kconfig
create mode 100644 drivers/pci/pwrseq/Makefile
create mode 100644 drivers/pci/pwrseq/pci-pwrseq-qca6390.c
create mode 100644 drivers/pci/pwrseq/pwrseq.c
create mode 100644 include/linux/pci-pwrseq.h
--
2.40.1
On Wed, Jan 17, 2024 at 10:08 AM Bartosz Golaszewski <[email protected]> wrote:
>
> From: Bartosz Golaszewski <[email protected]>
>
> The responses to the RFC were rather positive so here's a proper series.
Thanks for tackling this.
> 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 DT maintainers won't like adding any "fake" nodes not representing
> actual devices, we decided to reuse existing PCI infrastructure.
Thank you. :)
> 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.
Suspend/resume has been brought up already, but I disagree we can
worry about that later unless there is and always will be no power
sequencing during suspend/resume for all devices ever. Given the
supplies aren't standard, it wouldn't surprise me if standard PCI
power management isn't either. The primary issue I see with this
design is we will end up with 2 drivers doing the same power
sequencing: the platform driver for initial power on and the device's
PCI driver for suspend/resume.
Rob