public inbox for linux-perf-users@vger.kernel.org
 help / color / mirror / Atom feed
From: Leo Yan <leo.yan@arm.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
	Oliver Upton <oupton@kernel.org>,
	Shameer Kolothum <skolothumtho@nvidia.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Ian Rogers <irogers@google.com>,
	James Clark <james.clark@linaro.org>,
	Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-perf-users@vger.kernel.org
Subject: Re: REQUEST: Syncing tools/arch/arm64/include/asm/cputype.h with the kernel sources
Date: Mon, 16 Mar 2026 09:43:44 +0000	[thread overview]
Message-ID: <20260316094344.GA8048@e132581.arm.com> (raw)
In-Reply-To: <aba3Z0aelph_gQ6c@x1>

Hi Arnaldo,

[ + Mark ]

On Sun, Mar 15, 2026 at 10:43:03AM -0300, Arnaldo Carvalho de Melo wrote:
> Hi,
> 
> 	Can someone please address this perf build warning:
> 
>   make: Entering directory '/home/acme/git/perf-tools/tools/perf'
>   BUILD:   Doing 'make -j32' parallel build
> Warning: Kernel ABI header differences:
>   diff -u tools/arch/arm64/include/asm/cputype.h arch/arm64/include/asm/cputype.h
> 
> I tried updating that header and got the problems below.
> 
> I just merged perf-tools with upstream, will push to tmp.perf-tools at:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools.git tmp.perf-tools
> 
> Thanks in advance,

Sorry that this issue has come up again.

A quick summary:

The plan was to extract the CPU ID definitions from cputype.h so that
kernel and userspace can share the same definitions.  This would avoid
keep syncing cputype.h between the kernel and userspace [1].

James worked on this a bit, and later Mark wanted to try a different
implementation.  However, we haven't posted formal patches yet.

To avoid extra burden on perf maintainers, I suggest removing the
cputype.h check in check-headers.sh.  In the short term, Arm developers
will take responsibility for keeping it up to date.  In the long term,
once the CPU ID refactoring is completed, we can do a proper cleanup of
cputype.h.

James, Mark, is this reasonable?

[1] https://lore.kernel.org/linux-perf-users/aFJ8bQh_30JMzF_-@J2N7QTR9R3/

> - Arnaldo
> 
> ⬢ [acme@toolbx perf-tools]$ git diff
> diff --git a/tools/arch/arm64/include/asm/cputype.h b/tools/arch/arm64/include/asm/cputype.h
> index 9b73c1aa3ad747ec..08860d482e60009f 100644
> --- a/tools/arch/arm64/include/asm/cputype.h
> +++ b/tools/arch/arm64/include/asm/cputype.h
> @@ -255,6 +255,16 @@
> 
>  #define read_cpuid(reg)                        read_sysreg_s(SYS_ ## reg)
> 
> +/*
> + * The CPU ID never changes at run time, so we might as well tell the
> + * compiler that it's constant.  Use this function to read the CPU ID
> + * rather than directly reading processor_id or read_cpuid() directly.
> + */
> +static inline u32 __attribute_const__ read_cpuid_id(void)
> +{
> +       return read_cpuid(MIDR_EL1);
> +}
> +
>  /*
>   * Represent a range of MIDR values for a given CPU model and a
>   * range of variant/revision values.
> @@ -290,31 +300,6 @@ static inline bool midr_is_cpu_model_range(u32 midr, u32 model, u32 rv_min,
>         return _model == model && rv >= rv_min && rv <= rv_max;
>  }
> 
> -static inline bool is_midr_in_range(u32 midr, struct midr_range const *range)
> -{
> -       return midr_is_cpu_model_range(midr, range->model,
> -                                      range->rv_min, range->rv_max);
> -}
> -
> -static inline bool
> -is_midr_in_range_list(u32 midr, struct midr_range const *ranges)
> -{
> -       while (ranges->model)
> -               if (is_midr_in_range(midr, ranges++))
> -                       return true;
> -       return false;
> ⬢ [acme@toolbx perf-tools]$ m
> make: Entering directory '/home/acme/git/perf-tools/tools/perf'
>   BUILD:   Doing 'make -j32' parallel build
> Warning: Kernel ABI header differences:
>   diff -u tools/arch/x86/include/asm/msr-index.h arch/x86/include/asm/msr-index.h
>   diff -u tools/arch/x86/include/uapi/asm/svm.h arch/x86/include/uapi/asm/svm.h
> 
> Auto-detecting system features:
> ...                                   libdw: [ on  ]
> ...                                   glibc: [ on  ]
> ...                                  libelf: [ on  ]
> ...                                 libnuma: [ on  ]
> ...                  numa_num_possible_cpus: [ on  ]
> ...                               libpython: [ on  ]
> ...                             libcapstone: [ on  ]
> ...                               llvm-perf: [ on  ]
> ...                                    zlib: [ on  ]
> ...                                    lzma: [ on  ]
> ...                                     bpf: [ on  ]
> ...                                  libaio: [ on  ]
> ...                                 libzstd: [ on  ]
> ...                              libopenssl: [ on  ]
> ...                                    rust: [ on  ]
> 
>   INSTALL libsubcmd_headers
>   INSTALL libapi_headers
>   INSTALL libperf_headers
>   INSTALL libsymbol_headers
>   INSTALL libbpf_headers
>   CC      /tmp/build/perf-tools/util/arm-spe.o
> util/arm-spe.c: In function ‘arm_spe__synth_ds’:
> util/arm-spe.c:986:43: error: passing argument 1 of ‘is_midr_in_range_list’ makes pointer from integer without a cast [-Wint-conversion]
>   986 |                 if (is_midr_in_range_list(midr, data_source_handles[i].midr_ranges)) {
>       |                                           ^~~~
>       |                                           |
>       |                                           u64 {aka long unsigned int}
> In file included from util/arm-spe.c:37:
> util/../../arch/arm64/include/asm/cputype.h:310:53: note: expected ‘const struct midr_range *’ but argument is of type ‘u64’ {aka ‘long unsigned int’}
>   310 | bool is_midr_in_range_list(struct midr_range const *ranges);
>       |                            ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
> util/arm-spe.c:986:21: error: too many arguments to function ‘is_midr_in_range_list’; expected 1, have 2
>   986 |                 if (is_midr_in_range_list(midr, data_source_handles[i].midr_ranges)) {
>       |                     ^~~~~~~~~~~~~~~~~~~~~       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> util/../../arch/arm64/include/asm/cputype.h:310:6: note: declared here
>   310 | bool is_midr_in_range_list(struct midr_range const *ranges);
>       |      ^~~~~~~~~~~~~~~~~~~~~
> make[4]: *** [/home/acme/git/perf-tools/tools/build/Makefile.build:95: /tmp/build/perf-tools/util/arm-spe.o] Error 1
> make[3]: *** [/home/acme/git/perf-tools/tools/build/Makefile.build:158: util] Error 2
> make[2]: *** [Makefile.perf:797: /tmp/build/perf-tools/perf-util-in.o] Error 2
> make[2]: *** Waiting for unfinished jobs....
> make[1]: *** [Makefile.perf:289: sub-make] Error 2
> make: *** [Makefile:119: install-bin] Error 2
> make: Leaving directory '/home/acme/git/perf-tools/tools/perf'
> ⬢ [acme@toolbx perf-tools]$

  reply	other threads:[~2026-03-16  9:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-15 13:43 REQUEST: Syncing tools/arch/arm64/include/asm/cputype.h with the kernel sources Arnaldo Carvalho de Melo
2026-03-16  9:43 ` Leo Yan [this message]
2026-03-16  9:51   ` Mark Rutland
2026-03-16 10:18     ` Leo Yan

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=20260316094344.GA8048@e132581.arm.com \
    --to=leo.yan@arm.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=irogers@google.com \
    --cc=james.clark@linaro.org \
    --cc=jolsa@kernel.org \
    --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=namhyung@kernel.org \
    --cc=oupton@kernel.org \
    --cc=skolothumtho@nvidia.com \
    /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