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 -- மணிவண்ணன் சதாசிவம்
