From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Ian Rogers <irogers@google.com>
Cc: James Clark <james.clark@linaro.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Namhyung Kim <namhyung@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>,
Adrian Hunter <adrian.hunter@intel.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Mike Leach <mike.leach@linaro.org>,
John Garry <john.g.garry@oracle.com>,
Will Deacon <will@kernel.org>, Leo Yan <leo.yan@linux.dev>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org,
Leo Yan <leo.yan@arm.com>
Subject: Re: [PATCH v3 00/12] perf cs-etm/arm-spe: Remove hard coded config fields
Date: Tue, 13 Jan 2026 17:51:05 -0300 [thread overview]
Message-ID: <aWawOTKpREcVTtUL@x1> (raw)
In-Reply-To: <CAP-5=fXrLck7XACML16hzQO-pHGXA+qAM69kDDC6Za4O5S=SmA@mail.gmail.com>
On Tue, Dec 16, 2025 at 01:00:32PM -0800, Ian Rogers wrote:
> On Fri, Dec 12, 2025 at 7:32 AM James Clark <james.clark@linaro.org> wrote:
> >
> > The specific config field that an event format attribute is in is
> > consistently hard coded, even though the API is supposed to be that the
> > driver publishes the config field name. To stop this pattern from being
> > copy pasted and causing problems in the future, replace them all with
> > calls to a new helper that returns the value that a user set.
> >
> > This reveals some issues in evsel__set_config_if_unset(). It doesn't
> > work with sparse bitfields, which are an unused but documented feature.
> > And it also only writes to the attr.config field. To fix it we need to
> > start tracking user changes for all config fields and then use existing
> > helper functions that support sparse bitfields. Some other refactoring
> > was also required and a test was added.
> >
> > Signed-off-by: James Clark <james.clark@linaro.org>
>
> Outside of some nits, for the series:
> Reviewed-by: Ian Rogers <irogers@google.com>
Are you ok with v4?
- Arnaldo
prev parent reply other threads:[~2026-01-13 20:51 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-12 15:32 [PATCH v3 00/12] perf cs-etm/arm-spe: Remove hard coded config fields James Clark
2025-12-12 15:32 ` [PATCH v3 01/12] perf parse-events: Refactor get_config_terms() to remove macros James Clark
2025-12-12 15:32 ` [PATCH v3 02/12] perf evsel: Support sparse fields in evsel__set_config_if_unset() James Clark
2025-12-12 15:32 ` [PATCH v3 03/12] perf parse-events: Track all user changed config bits James Clark
2025-12-16 20:39 ` Ian Rogers
2025-12-12 15:32 ` [PATCH v3 04/12] perf evsel: apply evsel__set_config_if_unset() to all config fields James Clark
2025-12-12 15:32 ` [PATCH v3 05/12] perf evsel: Add a helper to get the value of a config field James Clark
2025-12-16 20:44 ` Ian Rogers
2025-12-17 9:30 ` James Clark
2025-12-12 15:32 ` [PATCH v3 06/12] perf parse-events: Always track user config changes James Clark
2025-12-12 15:32 ` [PATCH v3 07/12] perf tests: Test evsel__set_config_if_unset() and config change tracking James Clark
2025-12-12 15:32 ` [PATCH v3 08/12] perf cs-etm: Make a helper to find the Coresight evsel James Clark
2025-12-12 15:32 ` [PATCH v3 09/12] perf cs-etm: Don't use hard coded config bits when setting up ETMCR James Clark
2025-12-12 15:32 ` [PATCH v3 10/12] perf cs-etm: Don't use hard coded config bits when setting up TRCCONFIGR James Clark
2025-12-12 15:32 ` [PATCH v3 11/12] perf cs-etm: Don't hard code config attribute when configuring the event James Clark
2025-12-12 15:32 ` [PATCH v3 12/12] perf arm-spe: Don't hard code config attribute James Clark
2025-12-16 21:00 ` [PATCH v3 00/12] perf cs-etm/arm-spe: Remove hard coded config fields Ian Rogers
2026-01-13 20:51 ` Arnaldo Carvalho de Melo [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aWawOTKpREcVTtUL@x1 \
--to=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=coresight@lists.linaro.org \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=john.g.garry@oracle.com \
--cc=jolsa@kernel.org \
--cc=leo.yan@arm.com \
--cc=leo.yan@linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mike.leach@linaro.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.