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.

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.

When the IRQ is asserted, the wake handler triggers a pm_runtime_resume().
The PM framework ensures that the parent device is resumed before the
child i.e controller driver which can bring back link to D0.

WAKE# is added in dts schema and merged based on this patch.
https://lore.kernel.org/all/20250515090517.3506772-1-krishna.chundru@oss.qualcomm.com/

[1]: https://lore.kernel.org/all/b2b91240-95fe-145d-502c-d52225497a34@nvidia.com/T/
[2]: https://lore.kernel.org/all/20171226023646.17722-1-jeffy.chen@rock-chips.com/

Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
---
Changes in v4:
- Move wake from portdrv to core framework to endpoint (Bjorn).
- Added support for multiple WAKE# case (Bjorn). But traverse from
  endpoint upstream port to root port till you get WAKE#. And use
  IRQF_SHARED flag for requesting interrupts.
- Link to v3: https://lore.kernel.org/r/20250605-wake_irq_support-v3-0-7ba56dc909a5@oss.qualcomm.com

Changes in v3:
- Update the commit messages, function names etc as suggested by Mani.
- return wake_irq if returns error (Neil).
- Link to v2: https://lore.kernel.org/r/20250419-wake_irq_support-v2-0-06baed9a87a1@oss.qualcomm.com

Changes in v2:
- Move the wake irq teardown after pcie_port_device_remove
  and move of_pci_setup_wake_irq before pcie_link_rcec (Lukas)
- teardown wake irq in shutdown also.
- Link to v1: https://lore.kernel.org/r/20250401-wake_irq_support-v1-0-d2e22f4a0efd@oss.qualcomm.com

---
Krishna Chaitanya Chundru (3):
      arm64: dts: qcom: sc7280: Add wake GPIO
      PM: sleep: wakeirq: Add support for custom IRQ flags in dedicated wake IRQ setup
      PCI: Add support for PCIe WAKE# interrupt

 arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts   |  1 +
 arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi |  1 +
 arch/arm64/boot/dts/qcom/sc7280-idp.dtsi       |  1 +
 drivers/base/power/wakeirq.c                   | 43 +++++++++++++++--
 drivers/pci/of.c                               | 66 ++++++++++++++++++++++++++
 drivers/pci/pci-driver.c                       | 10 ++++
 drivers/pci/pci.h                              | 10 ++++
 drivers/pci/probe.c                            |  2 +
 drivers/pci/remove.c                           |  1 +
 include/linux/pci.h                            |  2 +
 include/linux/pm_wakeirq.h                     |  6 +++
 11 files changed, 138 insertions(+), 5 deletions(-)
---
base-commit: 5f10a4bfd256d0ff64ef13baf7af7b1adf00740c
change-id: 20250329-wake_irq_support-79772fc8cd44

Best regards,
-- 
Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>

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

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

- Mani

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

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

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

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