[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aCxxA-4HEnZ-O2W0@wunner.de>
Date: Tue, 20 May 2025 14:09:39 +0200
From: Lukas Wunner <lukas@...ner.de>
To: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Cc: Shuai Xue <xueshuai@...ux.alibaba.com>, rostedt@...dmis.org,
linux-pci@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
linux-edac@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
helgaas@...nel.org, bhelgaas@...gle.com, tony.luck@...el.com,
bp@...en8.de, mhiramat@...nel.org, mathieu.desnoyers@...icios.com,
oleg@...hat.com, naveen@...nel.org, davem@...emloft.net,
anil.s.keshavamurthy@...el.com, mark.rutland@....com,
peterz@...radead.org, tianruidong@...ux.alibaba.com
Subject: Re: [PATCH v8] PCI: hotplug: Add a generic RAS tracepoint for
hotplug event
On Tue, May 20, 2025 at 12:44:38PM +0200, Lukas Wunner wrote:
> 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.
Thanks,
Lukas
Powered by blists - more mailing lists