[PATCH] perf vendor events arm64 AmpereOneX: Fix misspelled PublicDescription keys

[PATCH] perf vendor events arm64 AmpereOneX: Fix misspelled PublicDescription keys

[TAKANO Mitsuhiro]

Sixteen of the 28 entries in mmu.json spell PublicDescription as
"PublicDescrition"; the other 12 spell it correctly.  jevents.py reads
only the keys it asks for by name, so those 16 fields are dead.

Fixing them does not change the perf list output: every one of the 16
entries has a BriefDescription with the same text, and jevents.py drops
the long description when it equals the brief one (jevents.py:405).
Running jevents.py for arm64 before and after this change gives a
byte-identical generated string table.  This is a cleanup, not a fix for
anything a user can see.

The file becomes self-consistent again, and the field works if the brief
text is ever changed on its own.  No text, name, code or expression
changes.

Written with Hermes Agent, an LLM assistant; the tables were regenerated
with jevents.py on top of this change, perf was not rebuilt.

Signed-off-by: TAKANO Mitsuhiro <takano32@gmail.com>
---
 .../arch/arm64/ampere/ampereonex/mmu.json     | 32 +++++++++----------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/tools/perf/pmu-events/arch/arm64/ampere/ampereonex/mmu.json b/tools/perf/pmu-events/arch/arm64/ampere/ampereonex/mmu.json
index 66d83b680651..9457f9be4ecc 100644
--- a/tools/perf/pmu-events/arch/arm64/ampere/ampereonex/mmu.json
+++ b/tools/perf/pmu-events/arch/arm64/ampere/ampereonex/mmu.json
@@ -30,37 +30,37 @@
         "BriefDescription": "Data TLB translation cache hit on S2L2 walk cache entry"
     },
     {
-        "PublicDescrition": "Data TLB translation cache hit on S2L1 walk cache entry",
+        "PublicDescription": "Data TLB translation cache hit on S2L1 walk cache entry",
         "EventCode": "0xd805",
         "EventName": "MMU_D_TRANS_CACHE_HIT_S2L1_WALK",
         "BriefDescription": "Data TLB translation cache hit on S2L1 walk cache entry"
     },
     {
-        "PublicDescrition": "Data TLB translation cache hit on S2L0 walk cache entry",
+        "PublicDescription": "Data TLB translation cache hit on S2L0 walk cache entry",
         "EventCode": "0xd806",
         "EventName": "MMU_D_TRANS_CACHE_HIT_S2L0_WALK",
         "BriefDescription": "Data TLB translation cache hit on S2L0 walk cache entry"
     },
     {
-        "PublicDescrition": "Data-side S1 page walk cache lookup",
+        "PublicDescription": "Data-side S1 page walk cache lookup",
         "EventCode": "0xd807",
         "EventName": "MMU_D_S1_WALK_CACHE_LOOKUP",
         "BriefDescription": "Data-side S1 page walk cache lookup"
     },
     {
-        "PublicDescrition": "Data-side S1 page walk cache refill",
+        "PublicDescription": "Data-side S1 page walk cache refill",
         "EventCode": "0xd808",
         "EventName": "MMU_D_S1_WALK_CACHE_REFILL",
         "BriefDescription": "Data-side S1 page walk cache refill"
     },
     {
-        "PublicDescrition": "Data-side S2 page walk cache lookup",
+        "PublicDescription": "Data-side S2 page walk cache lookup",
         "EventCode": "0xd809",
         "EventName": "MMU_D_S2_WALK_CACHE_LOOKUP",
         "BriefDescription": "Data-side S2 page walk cache lookup"
     },
     {
-        "PublicDescrition": "Data-side S2 page walk cache refill",
+        "PublicDescription": "Data-side S2 page walk cache refill",
         "EventCode": "0xd80a",
         "EventName": "MMU_D_S2_WALK_CACHE_REFILL",
         "BriefDescription": "Data-side S2 page walk cache refill"
@@ -90,61 +90,61 @@
         "BriefDescription": "Level 2 instruction translation buffer allocation"
     },
     {
-        "PublicDescrition": "Instruction TLB translation cache hit on S1L2 walk cache entry",
+        "PublicDescription": "Instruction TLB translation cache hit on S1L2 walk cache entry",
         "EventCode": "0xd901",
         "EventName": "MMU_I_TRANS_CACHE_HIT_S1L2_WALK",
         "BriefDescription": "Instruction TLB translation cache hit on S1L2 walk cache entry"
     },
     {
-        "PublicDescrition": "Instruction TLB translation cache hit on S1L1 walk cache entry",
+        "PublicDescription": "Instruction TLB translation cache hit on S1L1 walk cache entry",
         "EventCode": "0xd902",
         "EventName": "MMU_I_TRANS_CACHE_HIT_S1L1_WALK",
         "BriefDescription": "Instruction TLB translation cache hit on S1L1 walk cache entry"
     },
     {
-        "PublicDescrition": "Instruction TLB translation cache hit on S1L0 walk cache entry",
+        "PublicDescription": "Instruction TLB translation cache hit on S1L0 walk cache entry",
         "EventCode": "0xd903",
         "EventName": "MMU_I_TRANS_CACHE_HIT_S1L0_WALK",
         "BriefDescription": "Instruction TLB translation cache hit on S1L0 walk cache entry"
     },
     {
-        "PublicDescrition": "Instruction TLB translation cache hit on S2L2 walk cache entry",
+        "PublicDescription": "Instruction TLB translation cache hit on S2L2 walk cache entry",
         "EventCode": "0xd904",
         "EventName": "MMU_I_TRANS_CACHE_HIT_S2L2_WALK",
         "BriefDescription": "Instruction TLB translation cache hit on S2L2 walk cache entry"
     },
     {
-        "PublicDescrition": "Instruction TLB translation cache hit on S2L1 walk cache entry",
+        "PublicDescription": "Instruction TLB translation cache hit on S2L1 walk cache entry",
         "EventCode": "0xd905",
         "EventName": "MMU_I_TRANS_CACHE_HIT_S2L1_WALK",
         "BriefDescription": "Instruction TLB translation cache hit on S2L1 walk cache entry"
     },
     {
-        "PublicDescrition": "Instruction TLB translation cache hit on S2L0 walk cache entry",
+        "PublicDescription": "Instruction TLB translation cache hit on S2L0 walk cache entry",
         "EventCode": "0xd906",
         "EventName": "MMU_I_TRANS_CACHE_HIT_S2L0_WALK",
         "BriefDescription": "Instruction TLB translation cache hit on S2L0 walk cache entry"
     },
     {
-        "PublicDescrition": "Instruction-side S1 page walk cache lookup",
+        "PublicDescription": "Instruction-side S1 page walk cache lookup",
         "EventCode": "0xd907",
         "EventName": "MMU_I_S1_WALK_CACHE_LOOKUP",
         "BriefDescription": "Instruction-side S1 page walk cache lookup"
     },
     {
-        "PublicDescrition": "Instruction-side S1 page walk cache refill",
+        "PublicDescription": "Instruction-side S1 page walk cache refill",
         "EventCode": "0xd908",
         "EventName": "MMU_I_S1_WALK_CACHE_REFILL",
         "BriefDescription": "Instruction-side S1 page walk cache refill"
     },
     {
-        "PublicDescrition": "Instruction-side S2 page walk cache lookup",
+        "PublicDescription": "Instruction-side S2 page walk cache lookup",
         "EventCode": "0xd909",
         "EventName": "MMU_I_S2_WALK_CACHE_LOOKUP",
         "BriefDescription": "Instruction-side S2 page walk cache lookup"
     },
     {
-        "PublicDescrition": "Instruction-side S2 page walk cache refill",
+        "PublicDescription": "Instruction-side S2 page walk cache refill",
         "EventCode": "0xd90a",
         "EventName": "MMU_I_S2_WALK_CACHE_REFILL",
         "BriefDescription": "Instruction-side S2 page walk cache refill"

base-commit: fa4ad798f6f681031775266044ba1b0cf3c670bd
-- 
2.53.0

Re: [PATCH] perf vendor events arm64 AmpereOneX: Fix misspelled PublicDescription keys

[James Clark]

On 08/11/2026 18:38, TAKANO Mitsuhiro wrote:
> Sixteen of the 28 entries in mmu.json spell PublicDescription as
> "PublicDescrition"; the other 12 spell it correctly.  jevents.py reads
> only the keys it asks for by name, so those 16 fields are dead.

Shouldn't jevents enforce some kind of schema? This seems like a bug in 
the generator that it's allowed. And we have all the json files in one 
repo, so we can fix everything when adding strict validation.

> 
> Fixing them does not change the perf list output: every one of the 16
> entries has a BriefDescription with the same text, and jevents.py drops
> the long description when it equals the brief one (jevents.py:405).
> Running jevents.py for arm64 before and after this change gives a
> byte-identical generated string table.  This is a cleanup, not a fix for
> anything a user can see.
> 
> The file becomes self-consistent again, and the field works if the brief
> text is ever changed on its own.  No text, name, code or expression
> changes.
> 
> Written with Hermes Agent, an LLM assistant; the tables were regenerated
> with jevents.py on top of this change, perf was not rebuilt.
> 
> Signed-off-by: TAKANO Mitsuhiro <takano32@gmail.com>
> ---
>   .../arch/arm64/ampere/ampereonex/mmu.json     | 32 +++++++++----------
>   1 file changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/tools/perf/pmu-events/arch/arm64/ampere/ampereonex/mmu.json b/tools/perf/pmu-events/arch/arm64/ampere/ampereonex/mmu.json
> index 66d83b680651..9457f9be4ecc 100644
> --- a/tools/perf/pmu-events/arch/arm64/ampere/ampereonex/mmu.json
> +++ b/tools/perf/pmu-events/arch/arm64/ampere/ampereonex/mmu.json
> @@ -30,37 +30,37 @@
>           "BriefDescription": "Data TLB translation cache hit on S2L2 walk cache entry"
>       },
>       {
> -        "PublicDescrition": "Data TLB translation cache hit on S2L1 walk cache entry",
> +        "PublicDescription": "Data TLB translation cache hit on S2L1 walk cache entry",
>           "EventCode": "0xd805",
>           "EventName": "MMU_D_TRANS_CACHE_HIT_S2L1_WALK",
>           "BriefDescription": "Data TLB translation cache hit on S2L1 walk cache entry"
>       },
>       {
> -        "PublicDescrition": "Data TLB translation cache hit on S2L0 walk cache entry",
> +        "PublicDescription": "Data TLB translation cache hit on S2L0 walk cache entry",
>           "EventCode": "0xd806",
>           "EventName": "MMU_D_TRANS_CACHE_HIT_S2L0_WALK",
>           "BriefDescription": "Data TLB translation cache hit on S2L0 walk cache entry"
>       },
>       {
> -        "PublicDescrition": "Data-side S1 page walk cache lookup",
> +        "PublicDescription": "Data-side S1 page walk cache lookup",
>           "EventCode": "0xd807",
>           "EventName": "MMU_D_S1_WALK_CACHE_LOOKUP",
>           "BriefDescription": "Data-side S1 page walk cache lookup"
>       },
>       {
> -        "PublicDescrition": "Data-side S1 page walk cache refill",
> +        "PublicDescription": "Data-side S1 page walk cache refill",
>           "EventCode": "0xd808",
>           "EventName": "MMU_D_S1_WALK_CACHE_REFILL",
>           "BriefDescription": "Data-side S1 page walk cache refill"
>       },
>       {
> -        "PublicDescrition": "Data-side S2 page walk cache lookup",
> +        "PublicDescription": "Data-side S2 page walk cache lookup",
>           "EventCode": "0xd809",
>           "EventName": "MMU_D_S2_WALK_CACHE_LOOKUP",
>           "BriefDescription": "Data-side S2 page walk cache lookup"
>       },
>       {
> -        "PublicDescrition": "Data-side S2 page walk cache refill",
> +        "PublicDescription": "Data-side S2 page walk cache refill",
>           "EventCode": "0xd80a",
>           "EventName": "MMU_D_S2_WALK_CACHE_REFILL",
>           "BriefDescription": "Data-side S2 page walk cache refill"
> @@ -90,61 +90,61 @@
>           "BriefDescription": "Level 2 instruction translation buffer allocation"
>       },
>       {
> -        "PublicDescrition": "Instruction TLB translation cache hit on S1L2 walk cache entry",
> +        "PublicDescription": "Instruction TLB translation cache hit on S1L2 walk cache entry",
>           "EventCode": "0xd901",
>           "EventName": "MMU_I_TRANS_CACHE_HIT_S1L2_WALK",
>           "BriefDescription": "Instruction TLB translation cache hit on S1L2 walk cache entry"
>       },
>       {
> -        "PublicDescrition": "Instruction TLB translation cache hit on S1L1 walk cache entry",
> +        "PublicDescription": "Instruction TLB translation cache hit on S1L1 walk cache entry",
>           "EventCode": "0xd902",
>           "EventName": "MMU_I_TRANS_CACHE_HIT_S1L1_WALK",
>           "BriefDescription": "Instruction TLB translation cache hit on S1L1 walk cache entry"
>       },
>       {
> -        "PublicDescrition": "Instruction TLB translation cache hit on S1L0 walk cache entry",
> +        "PublicDescription": "Instruction TLB translation cache hit on S1L0 walk cache entry",
>           "EventCode": "0xd903",
>           "EventName": "MMU_I_TRANS_CACHE_HIT_S1L0_WALK",
>           "BriefDescription": "Instruction TLB translation cache hit on S1L0 walk cache entry"
>       },
>       {
> -        "PublicDescrition": "Instruction TLB translation cache hit on S2L2 walk cache entry",
> +        "PublicDescription": "Instruction TLB translation cache hit on S2L2 walk cache entry",
>           "EventCode": "0xd904",
>           "EventName": "MMU_I_TRANS_CACHE_HIT_S2L2_WALK",
>           "BriefDescription": "Instruction TLB translation cache hit on S2L2 walk cache entry"
>       },
>       {
> -        "PublicDescrition": "Instruction TLB translation cache hit on S2L1 walk cache entry",
> +        "PublicDescription": "Instruction TLB translation cache hit on S2L1 walk cache entry",
>           "EventCode": "0xd905",
>           "EventName": "MMU_I_TRANS_CACHE_HIT_S2L1_WALK",
>           "BriefDescription": "Instruction TLB translation cache hit on S2L1 walk cache entry"
>       },
>       {
> -        "PublicDescrition": "Instruction TLB translation cache hit on S2L0 walk cache entry",
> +        "PublicDescription": "Instruction TLB translation cache hit on S2L0 walk cache entry",
>           "EventCode": "0xd906",
>           "EventName": "MMU_I_TRANS_CACHE_HIT_S2L0_WALK",
>           "BriefDescription": "Instruction TLB translation cache hit on S2L0 walk cache entry"
>       },
>       {
> -        "PublicDescrition": "Instruction-side S1 page walk cache lookup",
> +        "PublicDescription": "Instruction-side S1 page walk cache lookup",
>           "EventCode": "0xd907",
>           "EventName": "MMU_I_S1_WALK_CACHE_LOOKUP",
>           "BriefDescription": "Instruction-side S1 page walk cache lookup"
>       },
>       {
> -        "PublicDescrition": "Instruction-side S1 page walk cache refill",
> +        "PublicDescription": "Instruction-side S1 page walk cache refill",
>           "EventCode": "0xd908",
>           "EventName": "MMU_I_S1_WALK_CACHE_REFILL",
>           "BriefDescription": "Instruction-side S1 page walk cache refill"
>       },
>       {
> -        "PublicDescrition": "Instruction-side S2 page walk cache lookup",
> +        "PublicDescription": "Instruction-side S2 page walk cache lookup",
>           "EventCode": "0xd909",
>           "EventName": "MMU_I_S2_WALK_CACHE_LOOKUP",
>           "BriefDescription": "Instruction-side S2 page walk cache lookup"
>       },
>       {
> -        "PublicDescrition": "Instruction-side S2 page walk cache refill",
> +        "PublicDescription": "Instruction-side S2 page walk cache refill",
>           "EventCode": "0xd90a",
>           "EventName": "MMU_I_S2_WALK_CACHE_REFILL",
>           "BriefDescription": "Instruction-side S2 page walk cache refill"
> 
> base-commit: fa4ad798f6f681031775266044ba1b0cf3c670bd

Re: [PATCH] perf vendor events arm64 AmpereOneX: Fix misspelled PublicDescription keys

[TAKANO Mitsuhiro]

On 2026-11-09 10:24, James Clark wrote:

> Shouldn't jevents enforce some kind of schema? This seems like a bug in
> the generator that it's allowed. And we have all the json files in one
> repo, so we can fix everything when adding strict validation.

You are right, and there is a patch for it now:

https://lore.kernel.org/linux-perf-users/20261110193239.1741014-1-takano32@gmail.com/

It is not a schema, and I don't think it should be one yet.  It checks
nothing about types, required fields or value ranges.  It reports the keys
that jevents.py never asks for, when the spelling is a near miss for a
name it does ask for.  The failure here is that "PublicDescrition" was
never read, so the field was dead in 16 objects and nothing in the build or
in the tables said so.  What makes it cost something is the AMD tables:
"BriefDescript6ion" is the only description those three objects have, so
the generated table carries an empty text field for ls_inef_sw_pref.all on
Zen 4, Zen 5 and Zen 6.  In your table the output is unchanged, because the
value repeats BriefDescription and jevents.py drops the long description
when the two are equal - which is exactly why the typo could sit there
unnoticed.

I did not go the schema route because a table may legitimately carry a
field for another reader: the Intel tables carry Counter, CountersNumFixed,
CountersNumGeneric and Experimental, none of which jevents.py reads, and
Experimental is read by metric.py.  A schema, or an allow list inside
jevents.py, would mean asking every vendor that adds such a field to edit
perf's Python first.  So the set of names jevents.py reads is the only
list, and a key below the similarity cutoff is left alone.  It will not
catch everything -- a key that is a word of its own, or a misspelling that
lands on another existing key, gets through -- which is why I would rather
not present it as validation.

It reads the whole tree, not just the architecture being built: the typo is
cheapest to fix by whoever reads that table next, and that person may be
building something else -- this arm64 one shows up in a run over the whole
tree from an x86 box.  The exit status is 0 for a clean tree, 1 when
something was reported and 2 when a table could not be read.  make turns
both failures into its own status, so a script that has to tell them apart
should run pmu-events/jevents.py directly; for a person it is

  make -C tools/perf jevents-check

which reads the whole tree, and JEVENTS_CHECK_ARCH=x86 reads x86 plus the
common and test tables every build reads.  I kept it out of `make check`,
which is the sparse run over the C sources and needs a configured tree and a
C parser, and out of perf test as well: tests/pmu-events.c compares what it
generates from testarch/testcpu against a fixed list, and a key jevents.py
never read leaves no trace in the generated C, so a runtime test has
nothing to assert on.

It is not wired into the build: I had a version that ran it from
pmu-events/Build on every build and dropped it, because a report about a
table this build does not use would fail the build for everyone.  It costs
nothing when it does not run, since the tracking that makes a report
possible is switched off unless the check asked for it.

The two misspellings it finds were posted separately: the arm64 one is
this thread, the AMD one is

https://lore.kernel.org/linux-perf-users/20261108184600.3810059-1-takano32@gmail.com/

The generated tables are byte for byte the same as before on x86, arm64 and
the whole tree.

Written with Hermes Agent, an LLM assistant; the author reviewed it and ran
the checks it describes.

Re: [PATCH] perf vendor events arm64 AmpereOneX: Fix misspelled PublicDescription keys

[James Clark]

On 10/11/2026 19:42, TAKANO Mitsuhiro wrote:
> On 2026-11-09 10:24, James Clark wrote:
> 
>> Shouldn't jevents enforce some kind of schema? This seems like a bug in
>> the generator that it's allowed. And we have all the json files in one
>> repo, so we can fix everything when adding strict validation.
> 
> You are right, and there is a patch for it now:
> 
> https://lore.kernel.org/linux-perf-users/20261110193239.1741014-1-takano32@gmail.com/
> 
> It is not a schema, and I don't think it should be one yet.  It checks
> nothing about types, required fields or value ranges.  It reports the keys
> that jevents.py never asks for, when the spelling is a near miss for a

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.

> name it does ask for.  The failure here is that "PublicDescrition" was
> never read, so the field was dead in 16 objects and nothing in the build or
> in the tables said so.  What makes it cost something is the AMD tables:
> "BriefDescript6ion" is the only description those three objects have, so
> the generated table carries an empty text field for ls_inef_sw_pref.all on
> Zen 4, Zen 5 and Zen 6.  In your table the output is unchanged, because the
> value repeats BriefDescription and jevents.py drops the long description
> when the two are equal - which is exactly why the typo could sit there
> unnoticed.
> 
> I did not go the schema route because a table may legitimately carry a
> field for another reader: the Intel tables carry Counter, CountersNumFixed,
> CountersNumGeneric and Experimental, none of which jevents.py reads, and
> Experimental is read by metric.py.  A schema, or an allow list inside

But we can have a schema for json files that are checked into 
tools/perf/pmu-events/arch/ regardless of who reads them. The schema can 
say that "Counter" is valid as long as we agree that it's ok for that 
field to exist, even if jevents.py doesn't read it.

Then it's as simple as:

   from jsonschema import validate
   for path in Path(pmu-data).rglob("*.json"):
     validate(json.loads(path.read_text()), schema)

Where 'schema' is something like:

   schema = {
     "type": "array",
     "items": {
         "type": "object",
         "required": ["EventCode", "EventName", "BriefDescription"],
     ...

> jevents.py, would mean asking every vendor that adds such a field to edit
> perf's Python first.  So the set of names jevents.py reads is the only
> list, and a key below the similarity cutoff is left alone.  It will not
> catch everything -- a key that is a word of its own, or a misspelling that
> lands on another existing key, gets through -- which is why I would rather
> not present it as validation.
> 
> It reads the whole tree, not just the architecture being built: the typo is
> cheapest to fix by whoever reads that table next, and that person may be
> building something else -- this arm64 one shows up in a run over the whole
> tree from an x86 box.  The exit status is 0 for a clean tree, 1 when
> something was reported and 2 when a table could not be read.  make turns
> both failures into its own status, so a script that has to tell them apart
> should run pmu-events/jevents.py directly; for a person it is
> 
>    make -C tools/perf jevents-check
> 
> which reads the whole tree, and JEVENTS_CHECK_ARCH=x86 reads x86 plus the
> common and test tables every build reads.  I kept it out of `make check`,
> which is the sparse run over the C sources and needs a configured tree and a
> C parser, and out of perf test as well: tests/pmu-events.c compares what it
> generates from testarch/testcpu against a fixed list, and a key jevents.py
> never read leaves no trace in the generated C, so a runtime test has
> nothing to assert on.
> 
> It is not wired into the build: I had a version that ran it from
> pmu-events/Build on every build and dropped it, because a report about a
> table this build does not use would fail the build for everyone.  It costs
> nothing when it does not run, since the tracking that makes a report
> possible is switched off unless the check asked for it.
> 
> The two misspellings it finds were posted separately: the arm64 one is
> this thread, the AMD one is
> 
> https://lore.kernel.org/linux-perf-users/20261108184600.3810059-1-takano32@gmail.com/
> 
> The generated tables are byte for byte the same as before on x86, arm64 and
> the whole tree.
> 
> Written with Hermes Agent, an LLM assistant; the author reviewed it and ran
> the checks it describes.
> 

Re: [PATCH] perf vendor events arm64 AmpereOneX: Fix misspelled PublicDescription keys

[TAKANO Mitsuhiro]

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.

Re: [PATCH] perf vendor events arm64 AmpereOneX: Fix misspelled PublicDescription keys

[James Clark]

On 11/11/2026 13:35, TAKANO Mitsuhiro wrote:
> 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.
> 

The linked patches seem like a bigger change than what I'd expect. I'm 
not sure that's necessary for something conceptually as simple as 
"validate the json files".

I'm also a bit lost about the relationship between "[PATCH 0/3] perf 
jevents: Report the JSON keys that jevents.py never reads" and "[PATCH] 
perf jevents: Check the JSON keys that jevents.py never reads".


> 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

It could run if it exists and skip if not. Or we could make it a 
requirement, but that would require some agreement. The docs builder 
already has a pip requirements.txt file.

Even without jsonschema I can't see why a validator can't be written in 
less than 10 lines.

> 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.
>