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

[Bjorn Helgaas]

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@xxxxxxxxxxxxxx
> 
> 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@xxxxxxxxxxxxxx
> 
> 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