[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2025100255-catcall-drinkable-23f5@gregkh>
Date: Thu, 2 Oct 2025 08:44:30 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Anup Patel <apatel@...tanamicro.com>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Ian Rogers <irogers@...gle.com>, Alexandre Ghiti <alex@...ti.fr>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>, Namhyung Kim <namhyung@...nel.org>,
Mark Rutland <mark.rutland@....com>, Jiri Olsa <jolsa@...nel.org>,
Adrian Hunter <adrian.hunter@...el.com>,
Liang Kan <kan.liang@...ux.intel.com>,
Mayuresh Chitale <mchitale@...il.com>,
Anup Patel <anup@...infault.org>,
Atish Patra <atish.patra@...ux.dev>,
Andrew Jones <ajones@...tanamicro.com>,
Sunil V L <sunilvl@...tanamicro.com>,
linux-riscv@...ts.infradead.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/11] Linux RISC-V trace framework and drivers
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@...uxfoundation.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
Powered by blists - more mailing lists