[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251202171233.GF724103@e132581.arm.com>
Date: Tue, 2 Dec 2025 17:12:33 +0000
From: Leo Yan <leo.yan@....com>
To: Suzuki K Poulose <suzuki.poulose@....com>,
Mike Leach <mike.leach@...aro.org>,
James Clark <james.clark@...aro.org>,
Anshuman Khandual <anshuman.khandual@....com>,
Yeoreum Yun <yeoreum.yun@....com>, Will Deacon <will@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Tamas Petz <tamas.petz@....com>,
Tamas Zsoldos <tamas.zsoldos@....com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Namhyung Kim <namhyung@...nel.org>, Jiri Olsa <jolsa@...nel.org>,
Ian Rogers <irogers@...gle.com>,
Adrian Hunter <adrian.hunter@...el.com>, coresight@...ts.linaro.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-perf-users@...r.kernel.org
Subject: Re: [PATCH 11/19] coresight: trbe: Apply overwrite erratum for only
wrap event
On Tue, Dec 02, 2025 at 04:56:47PM +0000, Coresight ML wrote:
> On Tue, Dec 02, 2025 at 12:05:52PM +0000, Suzuki K Poulose wrote:
> > On 01/12/2025 11:22, Leo Yan wrote:
> > > The overwrite erratum occurs only on wrap events, so apply the extra
> > > wrap condition check in the workaround.
> > >
> > > Signed-off-by: Leo Yan <leo.yan@....com>
> > > ---
> > > drivers/hwtracing/coresight/coresight-trbe.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c
> > > index e579ea98523c24d23a0cd265dcdd0a46b52b52da..2600af12a8fb94bb8c74efda2a101aacd01b0b34 100644
> > > --- a/drivers/hwtracing/coresight/coresight-trbe.c
> > > +++ b/drivers/hwtracing/coresight/coresight-trbe.c
> > > @@ -714,7 +714,7 @@ static unsigned long trbe_get_trace_size(struct perf_output_handle *handle,
> > > * 64bytes. Thus we ignore the potential triggering of the erratum
> > > * on WRAP and limit the data to LIMIT.
> > > */
> > > - if (wrap)
> > > + if (wrap && trbe_may_overwrite_in_fill_mode(buf->cpudata))
> > > write = get_trbe_limit_pointer();
> >
> > This must be trbe_may_write_out_of_range() ?
>
> SDEN (e.g., [1]) is ambiguous about how the write pointer acts for the
> out-of-range erratum.
Thought again, we should not worry about out-of-range case.
As the workaround always ensures sufficient space beyond the limit, the
write pointer remains valid within the allocated buffer even if it is
updated and crosses that limit.
Powered by blists - more mailing lists