Re: [PATCH 00/11] Linux RISC-V trace framework and drivers

[Greg KH <gregkh@linuxfoundation.org>]

On Thu, Oct 02, 2025 at 12:09:23PM +0530, Anup Patel wrote:
> On Thu, Oct 2, 2025 at 11:56 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Thu, Oct 02, 2025 at 11:37:21AM +0530, Anup Patel wrote:
> > > This series adds initial support for RISC-V trace framework and drivers.
> > > The RISC-V trace v1.0 specification is already ratified and can be found at:
> > > https://github.com/riscv-non-isa/e-trace-encap/releases/tag/v1.0.0-ratified
> > > https://github.com/riscv-non-isa/tg-nexus-trace/releases/tag/1.0_Ratified
> > >
> > > The RISC-V trace framework and drivers are designed to be agnostic to the
> > > underlying trace protocol hence both RISC-V E-trace and RISC-V N-trace should
> > > work fine. The discovery of trace protocl parameters are left to user-space
> > > trace decoder.
> > >
> > > In ther future, there will be subsequent series adding:
> > > 1) Sysfs support
> >
> > why does "trace" need sysfs support?  No other cpu platform uses that
> > today, so why is a new user/kernel api needed?
> 
> We saw trace support for other architectures (e.g. ARM coresight) allowing
> trace start/stop through sysfs. If this is an obsolete or not preferred approach
> then we will deprioritize and possibly never add it.

Why is that needed for coresight and other arches do not need it?
Perhaps it should be deleted from that codebase instead?

thanks,

greg k-h