Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 8 Mar 2019 12:01:49 -0600
From:   Bjorn Helgaas <helgaas@kernel.org>
To:     linux-pci@vger.kernel.org
Cc:     Keith Busch <keith.busch@intel.com>,
        Lukas Wunner <lukas@wunner.de>,
        Russell Currey <ruscur@russell.cc>,
        Sam Bobroff <sbobroff@linux.ibm.com>,
        Oliver O'Halloran <oohall@gmail.com>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
        Sinan Kaya <okaya@kernel.org>,
        Mika Westerberg <mika.westerberg@linux.intel.com>,
        Matthew Wilcox <willy@infradead.org>,
        Frederick Lawler <fred@fredlawl.com>,
        linux-kernel@vger.kernel.org
Subject: [RFC] Log PCIe service info with pci_dev, not pcie_device
Message-ID: <20190308180149.GD214730@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

This is strictly a discussion starter, obviously not for application.

The portdrv driver binds to pci_dev for PCIe Root Ports and Switch
Ports.  It creates additional pcie_devices for each "service" (Power
Management events, AER, hotplug, Downstream Port Containment, etc).
These pcie_devices have their own struct device, in addition to the
one in the struct pci_dev.

Service drivers can then bind to those pcie_devices, and their
dev_printk output is typically associated with those, e.g.,

  pciehp 0000:80:10.0:pcie004: Slot #36 ...

The "pcie004" is a bitmask that identifies the particular service, but
I don't think it's very useful to users, especially since we already
have "pciehp" as the driver name.

I think the fact that pcie_device has its own struct device is
probably a design mistake and it would be better if those "services"
were more tightly integrated into the PCI core.

Changing that would be a big project that I don't want to tackle right
now, but I think a small step would be to simplify the dmesg logging
by doing it with the underlying pci_dev instead of the pcie_device.
For example, we could do something like the patch below, which would
change the dmesg output like this:

  - pciehp 0000:80:10.0:pcie004: Slot #36 AttnBtn- PwrCtrl- MRL- AttnInd+ PwrInd+ HotPlug+ Surprise+ Interlock- NoCompl- LLActRep+
  + pcieport 0000:80:10.0: pciehp: Slot #36 AttnBtn- PwrCtrl- MRL- AttnInd+ PwrInd+ HotPlug+ Surprise+ Interlock- NoCompl- LLActRep+

Please discuss :)

diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
index 7dd443aea5a5..2761778f2ecc 100644
--- a/drivers/pci/hotplug/pciehp_hpc.c
+++ b/drivers/pci/hotplug/pciehp_hpc.c
@@ -868,7 +868,7 @@ struct controller *pcie_init(struct pcie_device *dev)
 		PCI_EXP_SLTSTA_MRLSC | PCI_EXP_SLTSTA_CC |
 		PCI_EXP_SLTSTA_DLLSC | PCI_EXP_SLTSTA_PDC);
 
-	ctrl_info(ctrl, "Slot #%d AttnBtn%c PwrCtrl%c MRL%c AttnInd%c PwrInd%c HotPlug%c Surprise%c Interlock%c NoCompl%c LLActRep%c%s\n",
+	pci_info(pdev, "Slot #%d AttnBtn%c PwrCtrl%c MRL%c AttnInd%c PwrInd%c HotPlug%c Surprise%c Interlock%c NoCompl%c LLActRep%c%s\n",
 		(slot_cap & PCI_EXP_SLTCAP_PSN) >> 19,
 		FLAG(slot_cap, PCI_EXP_SLTCAP_ABP),
 		FLAG(slot_cap, PCI_EXP_SLTCAP_PCP),