linux-kernel - [RFC] Log PCIe service info with pci_dev, not pcie

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 8 Mar 2019 12:01:49 -0600
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     linux-pci@...r.kernel.org
Cc:     Keith Busch <keith.busch@...el.com>,
        Lukas Wunner <lukas@...ner.de>,
        Russell Currey <ruscur@...sell.cc>,
        Sam Bobroff <sbobroff@...ux.ibm.com>,
        Oliver O'Halloran <oohall@...il.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        Sinan Kaya <okaya@...nel.org>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Matthew Wilcox <willy@...radead.org>,
        Frederick Lawler <fred@...dlawl.com>,
        linux-kernel@...r.kernel.org
Subject: [RFC] Log PCIe service info with pci_dev, not pcie_device

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),