linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: "Bartosz Golaszewski" <brgl@bgdev.pl>,
	"Kalle Valo" <kvalo@kernel.org>,
	"David S . Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Bjorn Andersson" <andersson@kernel.org>,
	"Konrad Dybcio" <konrad.dybcio@linaro.org>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Will Deacon" <will@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Heiko Stuebner" <heiko@sntech.de>,
	"Jernej Skrabec" <jernej.skrabec@gmail.com>,
	"Chris Morgan" <macromorgan@hotmail.com>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Geert Uytterhoeven" <geert+renesas@glider.be>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Neil Armstrong" <neil.armstrong@linaro.org>,
	"Nícolas F . R . A . Prado" <nfraprado@collabora.com>,
	"Marek Szyprowski" <m.szyprowski@samsung.com>,
	"Peng Fan" <peng.fan@nxp.com>,
	"Robert Richter" <rrichter@amd.com>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"Jonathan Cameron" <Jonathan.Cameron@huawei.com>,
	"Terry Bowman" <terry.bowman@amd.com>,
	"Kuppuswamy Sathyanarayanan"
	<sathyanarayanan.kuppuswamy@linux.intel.com>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Huacai Chen" <chenhuacai@kernel.org>,
	"Alex Elder" <elder@linaro.org>,
	"Srini Kandagatla" <srinivas.kandagatla@linaro.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Jim Quinlan" <jim2101024@gmail.com>,
	james.quinlan@broadcom.com
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-msm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org,
	Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Subject: Re: [RFC 0/9] PCI: introduce the concept of power sequencing of PCIe devices
Date: Mon, 8 Jan 2024 20:08:33 -0800	[thread overview]
Message-ID: <a85dbfc3-e327-442a-9aab-5115f86944f7@gmail.com> (raw)
In-Reply-To: <20240104130123.37115-1-brgl@bgdev.pl>

Hello,

On 1/4/2024 5:01 AM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> 
> 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@gmail.com/

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.

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...

Thanks for doing this!
-- 
Florian

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

  parent reply	other threads:[~2024-01-09  4:09 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-04 13:01 [RFC 0/9] PCI: introduce the concept of power sequencing of PCIe devices Bartosz Golaszewski
2024-01-04 13:01 ` [RFC 1/9] arm64: dts: qcom: sm8250: describe the PCIe port Bartosz Golaszewski
2024-01-04 13:01 ` [RFC 2/9] arm64: dts: qcom: qrb5165-rb5: describe the WLAN module of QCA6390 Bartosz Golaszewski
2024-01-04 13:44   ` Dmitry Baryshkov
2024-01-04 15:13     ` Bartosz Golaszewski
2024-01-04 13:01 ` [RFC 3/9] PCI/portdrv: create platform devices for child OF nodes Bartosz Golaszewski
2024-01-06  1:05   ` Jeff Johnson
     [not found]   ` <20240109144327.GA10780@wunner.de>
2024-01-10 12:55     ` Bartosz Golaszewski
     [not found]       ` <20240110132853.GA6860@wunner.de>
2024-01-10 16:26         ` Bartosz Golaszewski
     [not found]           ` <20240110164105.GA13451@wunner.de>
2024-01-10 20:18             ` Bartosz Golaszewski
     [not found]               ` <20240111104211.GA32504@wunner.de>
2024-01-11 11:09                 ` Bartosz Golaszewski
     [not found]                   ` <20240111150201.GA28409@wunner.de>
2024-01-11 16:16                     ` Bartosz Golaszewski
2024-01-11 21:43                       ` Geert Uytterhoeven
2024-01-12  9:43                         ` Bartosz Golaszewski
     [not found]                       ` <20240112094312.GA8704@wunner.de>
2024-01-17 23:38                         ` Rob Herring
2024-01-10 20:41         ` Dan Williams
2024-01-11 12:40           ` Manivannan Sadhasivam
2024-01-04 13:01 ` [RFC 4/9] PCI: hold the rescan mutex when scanning for the first time Bartosz Golaszewski
2024-01-04 13:01 ` [RFC 5/9] PCI/pwrseq: add pwrseq core code Bartosz Golaszewski
2024-01-06  1:25   ` Jeff Johnson
2024-01-04 13:01 ` [RFC 6/9] dt-bindings: vendor-prefixes: add a PCI prefix for Qualcomm Atheros Bartosz Golaszewski
2024-01-04 14:49   ` Sebastian Reichel
     [not found]   ` <20240108191052.GA1893484-robh@kernel.org>
2024-01-08 19:22     ` Bartosz Golaszewski
2024-01-09  2:56       ` Rob Herring
2024-01-09  9:17         ` Krzysztof Kozlowski
2024-01-09  9:30           ` Bartosz Golaszewski
2024-01-04 13:01 ` [RFC 7/9] dt-bindings: wireless: ath11k: describe QCA6390 Bartosz Golaszewski
2024-01-04 15:57   ` Krzysztof Kozlowski
2024-01-09  9:13     ` Kalle Valo
2024-01-04 13:01 ` [RFC 8/9] PCI/pwrseq: add a pwrseq driver for QCA6390 Bartosz Golaszewski
2024-01-06  1:31   ` Jeff Johnson
2024-01-09  9:18     ` Kalle Valo
2024-01-09  9:34       ` Chen-Yu Tsai
2024-01-09 10:09         ` Kalle Valo
2024-01-09 10:14           ` Arnd Bergmann
2024-01-09 10:26             ` Chen-Yu Tsai
2024-01-09 10:38               ` Arnd Bergmann
2024-01-09 16:43             ` Kalle Valo
2024-01-09 16:46               ` Arnd Bergmann
2024-01-04 13:01 ` [RFC 9/9] arm64: defconfig: enable the PCIe power sequencing " Bartosz Golaszewski
2024-01-04 15:11 ` [RFC 0/9] PCI: introduce the concept of power sequencing of PCIe devices Sebastian Reichel
2024-01-08 15:24 ` Neil Armstrong
2024-01-08 16:10   ` Bartosz Golaszewski
2024-01-09  4:08 ` Florian Fainelli [this message]
2024-01-09  7:08   ` Chen-Yu Tsai
2024-01-09  7:41     ` Manivannan Sadhasivam
2024-01-09  9:29     ` Geert Uytterhoeven
2024-01-09  9:24   ` Kalle Valo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a85dbfc3-e327-442a-9aab-5115f86944f7@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=andersson@kernel.org \
    --cc=arnd@arndb.de \
    --cc=bartosz.golaszewski@linaro.org \
    --cc=bhelgaas@google.com \
    --cc=brgl@bgdev.pl \
    --cc=catalin.marinas@arm.com \
    --cc=chenhuacai@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=dan.j.williams@intel.com \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=elder@linaro.org \
    --cc=geert+renesas@glider.be \
    --cc=gregkh@linuxfoundation.org \
    --cc=heiko@sntech.de \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=james.quinlan@broadcom.com \
    --cc=jernej.skrabec@gmail.com \
    --cc=jim2101024@gmail.com \
    --cc=konrad.dybcio@linaro.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kuba@kernel.org \
    --cc=kvalo@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=macromorgan@hotmail.com \
    --cc=neil.armstrong@linaro.org \
    --cc=netdev@vger.kernel.org \
    --cc=nfraprado@collabora.com \
    --cc=pabeni@redhat.com \
    --cc=peng.fan@nxp.com \
    --cc=robh+dt@kernel.org \
    --cc=rrichter@amd.com \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=terry.bowman@amd.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).