Re: [RFC PATCH v12 1/5] dt-bindings: PCI: Add definition of PCIe WAKE# irq and PCI irq
From: "Rafael J. Wysocki" <rafael@kernel.org>
Date: 2017-12-30 00:31:17
Also in:
linux-pci, linux-pm, lkml
On Sat, Dec 30, 2017 at 12:50 AM, Rafael J. Wysocki [off-list ref] wrote:
On Fri, Dec 29, 2017 at 6:57 PM, Tony Lindgren [off-list ref] wrote:quoted
* Jeffy Chen [off-list ref] [171226 02:11]:quoted
We are going to handle PCIe WAKE# pin for PCI devices in the pci core, so add definitions of the optional PCIe WAKE# pin for PCI devices. Also add an definition of the optional PCI interrupt pin for PCI devices to distinguish it from the PCIe WAKE# pin.quoted
--- a/Documentation/devicetree/bindings/pci/pci.txt +++ b/Documentation/devicetree/bindings/pci/pci.txt@@ -24,3 +24,13 @@ driver implementation may support the following properties: unsupported link speed, for instance, trying to do training for unsupported link speed, etc. Must be '4' for gen4, '3' for gen3, '2' for gen2, and '1' for gen1. Any other values are invalid. + +PCI devices may support the following properties:This should say PCI ports instead of PCI devices.No, it is more accurate to say "PCI devices". Well, it actually gets somewhat confusing, because in the PCI terminology a "PCI device" means a physical piece of hardware that can be put into a single "slot" (think socket on a board) and may consist up to 8 functional units called "functions" which are each represented by a struct pci_dev. So there may be up to 8 struct pci_dev objects per "PCI device" (as per the standard language) and, BTW, drivers bind to functions (via the struct pci_dev objects). Now, WAKE# is shared by all functions within the same "PCI device" (I'm not sure if the standard specifies that directly, but at least it appears to be treated as an obvious physical limitation), so it may be useful to represent the "slot" or "device" level in the DT even though it has no struct device based representation in the kernel.
Within the convention that bridges represent "everything below them" as far as WAKE# is concerned, it can say "The following properties may be provided for PCI bridges:" and the description below should explain the convention. Thanks, Rafael