linux-kernel - Re: [PATCH v4 0/3] PCI: 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] [day] [month] [year] [list]

Message-ID: <rybngetujsbwx7j7ibnqpkyqdhat3gkqjzephrmluirxtgartb@753pwgb3xmvq>
Date: Wed, 27 Aug 2025 19:28:36 +0530
From: Manivannan Sadhasivam <mani@...nel.org>
To: Bjorn Helgaas <helgaas@...nel.org>
Cc: Krishna Chaitanya Chundru <krishna.chundru@....qualcomm.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>, "Rafael J. Wysocki" <rafael@...nel.org>, 
	Pavel Machek <pavel@...nel.org>, Len Brown <lenb@...nel.org>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Danilo Krummrich <dakr@...nel.org>, 
	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@....com, linux-pm@...r.kernel.org, 
	Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Subject: Re: [PATCH v4 0/3] PCI: Add support for PCIe WAKE# interrupt

On Mon, Aug 04, 2025 at 10:50:23AM GMT, Bjorn Helgaas wrote:
> On Mon, Aug 04, 2025 at 03:45:05PM +0530, Manivannan Sadhasivam wrote:
> > On Fri, Aug 01, 2025 at 04:29:41PM GMT, Krishna Chaitanya Chundru wrote:
> > > PCIe WAKE# interrupt is needed for bringing back PCIe device state
> > > from D3cold to D0.
> > > 
> > > This is pending from long time, there was two attempts done
> > > previously to add WAKE# support[1], [2]. Those series tried to add
> > > support for legacy interrupts along with WAKE#. Legacy interrupts
> > > are already available in the latest kernel and we can ignore them.
> > > For the wake IRQ the series is trying to use interrupts property
> > > define in the device tree.
> > > 
> > > This series is using gpio property instead of interrupts, from
> > > gpio desc driver will allocate the dedicate IRQ.
> > > 
> > > According to the PCIe specification 6, sec 5.3.3.2, there are two
> > > defined wakeup mechanisms: Beacon and WAKE# for the Link wakeup
> > > mechanisms to provide a means of signaling the platform to
> > > re-establish power and reference clocks to the components within
> > > its domain. Adding WAKE# support in PCI framework.
> > > 
> > > According to the PCIe specification, multiple WAKE# signals can
> > > exist in a system. In configurations involving a PCIe switch, each
> > > downstream port (DSP) of the switch may be connected to a separate
> > > WAKE# line, allowing each endpoint to signal WAKE# independently.
> > > To support this, the WAKE# should be described in the device tree
> > > node of the upstream bridge to which the endpoint is connected.
> > > For example, in a switch-based topology, the WAKE# GPIO can be
> > > defined in the DSP of the switch. In a direct connection scenario,
> > > the WAKE# can be defined in the root port. If all endpoints share
> > > a single WAKE# line, the GPIO should be defined in the root port.
> > 
> > I think you should stop saying 'endpoint' here and switch to 'slot'
> > as that's the terminology the PCIe spec uses while defining WAKE#.
> 
> I think the main question is where WAKE# is terminated.  It's asserted
> by an "add-in card" (PCIe CEM r6.0, sec 2.3) or a "component" or
> "Function" (PCIe Base r7.0, sec 5.3.3.2).  A slot can provide a WAKE#
> wire, and we need to know what the other end is connected to.
> 
> AFAICS, WAKE# routing is unrelated to the PCIe topology *except* that
> in "applications where Beacon is used on some Ports of the Switch and
> WAKE# is used for other Ports," WAKE# must be connected to the Switch
> so it can translate it to Beacon (PCIe r7.0, sec 5.3.3.2).
> 
> So we can't assume WAKE# is connected to the Port leading to the
> component that asserts WAKE#.
> 

I've submitted a PR to add wake-gpios to the endpoint node:
https://github.com/devicetree-org/dt-schema/pull/170

- Mani

-- 
மணிவண்ணன் சதாசிவம்