[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aHtFG3QsdohG466k@wunner.de>
Date: Sat, 19 Jul 2025 09:11:23 +0200
From: Lukas Wunner <lukas@...ner.de>
To: Shuai Xue <xueshuai@...ux.alibaba.com>
Cc: Bjorn Helgaas <helgaas@...nel.org>,
Matthew W Carlis <mattc@...estorage.com>,
Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
anil.s.keshavamurthy@...el.com, bhelgaas@...gle.com, bp@...en8.de,
davem@...emloft.net, linux-edac@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
linux-trace-kernel@...r.kernel.org, mark.rutland@....com,
mathieu.desnoyers@...icios.com, mhiramat@...nel.org,
naveen@...nel.org, oleg@...hat.com, peterz@...radead.org,
rostedt@...dmis.org, tianruidong@...ux.alibaba.com,
tony.luck@...el.com
Subject: Re: [PATCH v8] PCI: hotplug: Add a generic RAS tracepoint for
hotplug event
On Sat, Jul 19, 2025 at 01:23:28PM +0800, Shuai Xue wrote:
> <...>-120 [002] ..... 104.864051: pci_hp_event: 0000:00:03.0 slot:30, event:PCI_HOTPLUG_CARD_PRESENT
> <...>-120 [002] ..... 104.864081: pci_hp_event: 0000:00:03.0 slot:30, event:PCI_HOTPLUG_LINK_UP
Somehow I liked the simple "Link Up" and "Card present" strings more
than this. :)
The PCI_HOTPLUG substring repeats what pci_hp_event already betrays,
that this is a hotplug event.
> irq/57-pciehp-120 [002] ..... 104.990434: pci_link_event: 0000:00:03.0 cur_bus_speed:20, max_bus_speed:23, width:1, flit_mode:0, reason:5
> irq/57-pciehp-120 [002] ..... 104.992377: pci_link_event: 0000:00:03.0 cur_bus_speed:20, max_bus_speed:23, width:1, flit_mode:0, reason:0
This contains a lot of terminology specific to PCI *Express*
(versus Conventional PCI or PCI-X). Either it needs to be
"pcie_link_event" or we need to come up with a structure that
works for non-PCIe as well.
PCI links can be tunneled over Thunderbolt, in this case the
link speed is fixed to 2.5 GT/s (USB4 v1.0 sec 11.2.1), but
in reality is governed by the speed of the Thunderbolt fabric
(which can even be asymmetric). Do we want to report the
virtual 2.5 GT/s in this case or the actual Thunderbolt speed?
Or do we want a separate trace event for Thunderbolt?
For Root and Downstream Ports, the physical "port" points "downstream",
whereas for Upstream Ports and Endpoints, the physical "port" points
"upstream". Software interpreting the trace event may want to know
the direction (or whatever one wants to call it) because it cannot
tell from the address 0000:00:03.0 what the PCIe type is. Having to
look this up in lspci seems cumbersome. So it may be worthwhile to
include either the port's direction or the device's PCIe type in the
trace event.
Of course, hotplug only exists at Root or Downstream Ports, so any
trace event generated from the PCIe hotplug driver will pertain to
a downstream-facing port. But the bandwidth controller also binds
to Upstream Ports and its trace events may thus pertain to link speed
changes at an upstream-facing port.
Thanks,
Lukas
Powered by blists - more mailing lists