From: TAKANO Mitsuhiro <takano32@gmail.com>
To: James Clark <james.clark@linaro.org>
Cc: linux-perf-users@vger.kernel.org,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Ian Rogers <irogers@google.com>,
John Garry <john.garry@linux.dev>,
Ilkka Koskinen <ilkka@os.amperecomputing.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] perf vendor events arm64 AmpereOneX: Fix misspelled PublicDescription keys
Date: Wed, 11 Nov 2026 13:35:48 +0000 [thread overview]
Message-ID: <179440414898.2353714.11591904089911934138@gmail.com> (raw)
In-Reply-To: <39ac224f-2903-496e-9a08-b4c5a33dc87f@linaro.org>
On 2026-11-11 10:16, James Clark wrote:
> IMO I would rather have something that's incredibly strict and simple,
> or nothing at all. Having to work around edge cases and report near
> misses doesn't sound great.
Agreed, and the near-miss report is gone. The series is posted again:
https://lore.kernel.org/linux-perf-users/20261111132622.2349165-1-takano32@gmail.com/
The check is now a fixed list of the 51 keys a json object under arch/ may
carry: 47 of them jevents.py reads, one more metric.py reads, and three are
read by nothing although the tables hold them (Counter, CountersNumFixed,
CountersNumGeneric). A key outside that list is reported with the object
that carries it. There is no cut-off, no similarity and nothing that
depends on what a run of the generator happened to read, so there is no
edge case left to work around.
It still runs as "make check-jevents" and as a perf test rather than as part
of the build, and on the tree today it reports exactly the two misspellings
we have, the 16 in this file and 3 in the AMD tables, so it wants those
fixes in front of it or together with it.
The one thing I did not do is put the list in a json schema file, because
perf's build would then require jsonschema, which it does not use today and
which is not in every builder's python. The list holds the same names that
a schema with "additionalProperties": false would say. If you would rather
have the schema file and take the dependency, it is a small change from
here.
next prev parent reply other threads:[~2026-11-11 13:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-08 18:38 TAKANO Mitsuhiro
2026-11-09 10:24 ` James Clark
2026-11-10 19:42 ` TAKANO Mitsuhiro
2026-11-11 10:16 ` James Clark
2026-11-11 13:35 ` TAKANO Mitsuhiro [this message]
2026-11-11 14:03 ` James Clark
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=179440414898.2353714.11591904089911934138@gmail.com \
--to=takano32@gmail.com \
--cc=acme@kernel.org \
--cc=ilkka@os.amperecomputing.com \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=john.garry@linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=namhyung@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®