Hi Steven,

在 2026/02/24 星期二 22:16, Steven Rostedt 写道:
On Tue, 24 Feb 2026 09:11:15 -0500
Steven Rostedt <[email protected]> wrote:

+#ifdef CONFIG_TRACING
+static void rockchip_pcie_ltssm_trace_work(struct work_struct *work)
+{
+       struct rockchip_pcie *rockchip = container_of(work,
+                                               struct rockchip_pcie,
+                                               trace_work.work);
+       struct dw_pcie *pci = &rockchip->pci;
+       enum dw_pcie_ltssm state;
+       u32 i, l1ss, prev_val = DW_PCIE_LTSSM_UNKNOWN, rate, val;
+
+       if (!pci_ltssm_tp_enabled())
+               goto skip_trace;

You can use:

        if (!trace_pcie_ltssm_state_transition_enabled())
                goto skip_trace;

The above is a static branch. That means when tracing is disabled, it is
basically:

        goto skip_trace;

and when tracing is enabled it is a nop.

I must admit I borrow it from arch/powerpc/include/asm/trace.h and
include/trace/events/i2c.h for reference, where the reg and unreg
just increase and decrease the ref count to indicate if the tp
should be continued. Sure, the static branch could be used instead,
even without reg and unreg implementation.



..

+}
+

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


Reply via email to