Thread (37 messages) 37 messages, 5 authors, 2025-07-26

Re: [PATCH v8] PCI: hotplug: Add a generic RAS tracepoint for hotplug event

From: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date: 2025-05-20 12:53:05
Also in: linux-edac, linux-pci, lkml

On Tue, 20 May 2025, Lukas Wunner wrote:
On Tue, May 20, 2025 at 12:44:38PM +0200, Lukas Wunner wrote:
quoted
Link speed changes and device plug/unplug events are orthogonal,
I don't think they should be mixed together in the same event.

A link speed event can be signaled simultaneously to a plug event
and then user space can decide in which type of event it's
interested in.

That also avoids the awkwardness of having N/A values for the
link speed on unplug.
After thinking about this some more:

A link speed event could contain a "reason" field
which indicates why the link speed changed,
e.g. "hotplug", "autonomous", "thermal", "retrain", etc.

In other words, instead of mixing the infomation for hotplug
and link speed events together in one event, a separate link
speed event could point to hotplug as one possible reason for
the new speed.
It will be somewhat challenging to link LBMS into what caused it, 
especially in cases where there is more than one LBMS following a single 
Link Retraining.

Do you have opinion on should the event be only recorded from LBMS/LABS 
if the speed changed from the previous value? The speed should probably 
also be reported also for the first time (initial enumeration, hotplugging 
a new board).

-- 
 i.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help