Re: [PATCH v4 0/3] PCI: Add support for PCIe WAKE# interrupt

[Bjorn Helgaas <helgaas@kernel.org>]

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

> > During endpoint probe, the driver searches for the WAKE# in its
> > immediate upstream bridge. If not found, it continues walking up
> > the hierarchy until it either finds a WAKE# or reaches the root
> > port. Once found, the driver registers the wake IRQ in shared
> > mode, as the WAKE# may be shared among multiple endpoints.
> 
> I don't think we should walk the hierarchy all the way up to RP. If
> the slot supports WAKE#, it should be defined in the immediate
> bridge node of the endpoint (as DT uses bridge node to described the
> slot). Otherwise, if the slot doesn't use WAKE#, walking up till RP
> may falsely assign wake IRQ to the endpoint.

I don't think we can walk the PCIe hierarchy because in general WAKE#
routing is not related to that hierarchy.

Bjorn