[PATCH v4 02/12] rvtrace: Initial implementation of driver framework

[Zane Leung]

On 7/3/2026 3:41 PM, Greg KH wrote:
> On Fri, Jul 03, 2026 at 03:32:50PM +0800, Zane Leung wrote:
>> On 7/3/2026 1:41 PM, Greg KH wrote:
>>> On Thu, Jul 02, 2026 at 04:19:53PM +0800, Zane Leung wrote:
>>>> Hi, 
>>>>
>>>> Based on the current framework, I am concerned about how to support RISC-V ATB and reuse the Coresight component (ETB/tmc/TPIU) in the future.
>>> That is very vague.  Please provide specific examples.
>> According to the /trace control interface/ [1] spec: "The ATB Bridge allows sending RISC-V trace to Arm CoreSight 
>>
>> infrastructure (instead of RISC-V compliant sink defined in this document) as an ATB initiator. ATB Bridge is not 
>>
>> needed for RISC-V only systems."
>>
>> For ATB Bridge, read trace using Coresight components (ETB/TMC/TPIU),  so we need also ARM coresight driver in
>> RISC-V trace systems. Current framework seems to only be applicable to RISC-V only systems, and does not support
>> ATB and  ARM coresight use case like the K3 (K3 SoC contains RISC-V Encoder, Funnel, ATB, CoreSight Funnel, and 
>>
>> CoreSight TMC components). For more discussion, please refer to [2].
>>
>>
>> [1]: https://docs.riscv.org/reference/trace-control-interface/v1.0/tci_system_overview.html#atb-bridge
>> [2]: https://lore.kernel.org/all/20260414034153.3272485-1-liangzhen@linux.spacemit.com/
> So, what specifically does this mean?  Please provide review comments
> for the code itself.

The issue I pointed out is not about specific lines of code, but about the entire Riscv trace driver registration and building a path from source ->
sink did not take into account the application of arm_comesight. the current patch set assumes a rigid, homogeneous RISC-V-only topology.

Specifically, if we have ARM coresight components, how can we reuse them like, funnel (drivers/hwtracing/coresight/coresight-funnel.c) , 

TMC (drivers/hwtracing/coresight/coresight-funnel.c) , TPIU (drivers/hwtracing/coresight/coresight-tpiu.c) and so on based on the current

framework.


>
> We write code for stuff we have now, today.  If future needs change, we
> change the code to handle that then.

I believe that if the basic framework for RISC-V does not consider compatibility with ARM Coresight, once the framework is fixed, there will be greater resistance to future modifications. 

> The only problem is with user/kernel apis, those need to be nailed down
> so that they don't change.  I can't tell here if you are only referring
> to the in-kernel stuff, or user/kernel apis, sorry.
>
> thanks,
>
> greg k-h


I believe that RISC-V tracing is coresight-alike, where have encoders/funnel/sink/bridge+coresight_comp. 
I think we should abstract some of CoreSight's core logic so that it can Both coresight and rvtrace can be reused.
General logic for building paths from source -> Sink and perf_pmu should be universal in coresight/rvtrace and 

future architectures. 


thanks,

Zane