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
