linux-kernel - Re: [PATCH v3 2/2] PCI/portdrv: Add support for PCIe wake interrupt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250609223428.GA756387@bhelgaas>
Date: Mon, 9 Jun 2025 17:34:28 -0500
From: Bjorn Helgaas <helgaas@...nel.org>
To: Manivannan Sadhasivam <mani@...nel.org>
Cc: Krishna Chaitanya Chundru <krishna.chundru@....qualcomm.com>,
	Brian Norris <briannorris@...omium.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Tony Lindgren <tony@...mide.com>,
	JeffyChen <jeffy.chen@...k-chips.com>,
	Bjorn Andersson <andersson@...nel.org>,
	Konrad Dybcio <konradybcio@...nel.org>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	cros-qcom-dts-watchers@...omium.org,
	Bjorn Helgaas <bhelgaas@...gle.com>, linux-arm-msm@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-pci@...r.kernel.org, quic_vbadigan@...cinc.com,
	quic_mrana@...cinc.com, Sherry Sun <sherry.sun@....com>
Subject: Re: [PATCH v3 2/2] PCI/portdrv: Add support for PCIe wake interrupt

On Mon, Jun 09, 2025 at 05:29:49PM +0530, Manivannan Sadhasivam wrote:
> + Brian, Rafael, Tony, Jeffy (who were part of the previous attempt to add WAKE#
> GPIO/interrupt support:
> https://lore.kernel.org/linux-pci/20171225114742.18920-1-jeffy.chen@rock-chips.com
> 
> On Mon, Jun 09, 2025 at 11:27:49AM +0530, Krishna Chaitanya Chundru wrote:
> > On 6/6/2025 1:56 AM, Bjorn Helgaas wrote:
> > > On Thu, Jun 05, 2025 at 10:54:45AM +0530, Krishna Chaitanya Chundru wrote:
> > > > PCIe wake interrupt is needed for bringing back PCIe device state
> > > > from D3cold to D0.
> > > 
> > > Does this refer to the WAKE# signal or Beacon or both?  I guess the
> > > comments in the patch suggest WAKE#.  Is there any spec section we can
> > > cite here?
> > > 
> > we are referring only WAKE# signal, I will add the PCIe spec r6.0, sec
> > 5.3.3.2 in next patch version.
> > > > Implement new functions, of_pci_setup_wake_irq() and
> > > > of_pci_teardown_wake_irq(), to manage wake interrupts for PCI devices
> > > > using the Device Tree.
> > > > 
> > > >  From the port bus driver call these functions to enable wake support
> > > > for bridges.
> > > 
> > > What is the connection to bridges and portdrv?  WAKE# is described in
> > > PCIe r6.0, sec 5.3.3.2, and PCIe CEM r6.0, sec 2.3, but AFAICS neither
> > > restricts it to bridges.
> 
> You are right. WAKE# is really a PCIe slot/Endpoint property and
> doesn't necessarily belong to a Root Port/Bridge. But the problem is
> with handling the Wake interrupt in the host. For instance, below is
> the DT representation of the PCIe hierarchy:
> 
> 	PCIe Host Bridge
> 		|
> 		v
> 	PCIe Root Port/Bridge
> 		|
> 		|
> 		v
> PCIe Slot <-------------> PCIe Endpoint
> 
> DTs usually define both the WAKE# and PERST# GPIOs
> ({wake/reset}-gpios property) in the PCIe Host Bridge node. But we
> have decided to move atleast the PERST# to the Root Port node since
> the PERST# lines are per slot and not per host bridge.
> 
> Similar interpretation applies to WAKE# as well, but the major
> difference is that it is controlled by the endpoints, not by the
> host (RC/Host Bridge/Root Port). The host only cares about the
> interrupt that rises from the WAKE# GPIO.  The PCIe spec, r6.0,
> Figure 5-4, tells us that the WAKE# is routed to the PM controller
> on the host. In most of the systems that tends to be true as the
> WAKE# is not tied to the PCIe IP itself, but to a GPIO controller in
> the host.

If WAKE# is supported at all, it's a sideband signal independent of
the link topology.  PCIe CEM r6.0, sec 2.3, says WAKE# from multiple
connectors can be wire-ORed together, or can have individual
connections to the PM controller.

> In this case, the PCI core somehow needs to know the IRQ number
> corresponding to the WAKE# GPIO, so that it can register an IRQ
> handler for it to wakeup the endpoint when an interrupt happens.
> Previous attempts [1], tried to add a new DT property for the
> interrupts:
> https://lore.kernel.org/linux-pci/20171225114742.18920-2-jeffy.chen@rock-chips.com
> 
> But that doesn't seem to fly. So Krishna came with the proposal to
> reuse the WAKE# GPIO defined in the Root Port node (for DTs that
> have moved the properties out of the Host Bridge node) and extract
> the IRQ number from it using gpiod_to_irq() API.

I don't think we can assume a single WAKE# GPIO in a Root Port, as
above.  I think we'll have to start looking at the endpoint and search
upward till we find one.

Bjorn