[PATCH v4 3/3] PCI: dw-rockchip: Add pcie_ltssm_state_transition trace support

[Shawn Lin]

Hi Steven,

在 2026/02/24 星期二 22:16, Steven Rostedt 写道:
> On Tue, 24 Feb 2026 09:11:15 -0500
> Steven Rostedt <rostedt at goodmis.org> wrote:
> 

...

>>> +	}
>>> +
>>> +skip_trace:
>>> +	schedule_delayed_work(&rockchip->trace_work, msecs_to_jiffies(5000));
>>> +}
>>> +
> 
> Hmm, so basically you only want to call the work when tracing is
> enabled? That's what I was thinking should be enabled by the reg and
> unreg functions. That is, the reg should enabled the delayed work, and
> the unreg should disable it from being called.
> 
> This looks like it calls the work regardless of if tracing is enabled
> or not. Why waste the cycles when tracing is disabled?
> 


I looked into implementing reg and unreg callbacks to directly schedule
and cancel the delayed work. The challenge is that this tracepoint
belongs to the shared PCI subsystem trace hierarchy, while the polling
work itself is per-controller. I haven't found a clean way to register
per-driver callbacks in this common context.

Creating a separate Rockchip-specific tracepoint via
tracepoint_probe_register() would detach it from the standard PCIe trace
event hierarchy, which seems undesirable.

As a practical middle ground, I implement reg and unreg to maintain a
user count like this v4. All drivers using this tracepoint would then
rely on the count to gate their work execution, making the delayed work
essentially a no-op when tracing is disabled.

Alternatively, we could simply revert to the V3 approach and rely
entirely on the trace_pcie_ltssm_state_transition_enabled() static
branch check, which would remove the need for reg and unreg altogether.

If you have better suggestions or can point me to a preferred pattern 
for this, I'd appreciate your advice.

> -- Steve
>