On Mon, Jun 16, 2025 at 06:47:25PM +0100, Mark Rutland wrote:

[...]

quoted

quoted

ok this sounds just like as before except rename the midr check function and modify the
users in perf. will do in below steps:
- move cpu_errata_set_target_impl()/is_midr_in_range_list() out of cputype.h
  since they're only used in the kernel with errata information
- introduce is_target_midr_in_range_list() in cputype.h to test certain MIDR
  is within the ranges. (is_perf_midr_in_range_list() only make sense in
  userspace and is a bit strange to me in a kernel header). maybe reimplement
  is_midr_in_range_list() with is_target_midr_in_range_list() otherwise there's
  no users in kernel
- copy cputype.h to userspace and make users use new is_target_midr_in_range_list()

this will avoid touching the kernel too much and userspace don't need to implement
a separate function.

My understanding is we don't need to touch anything in kernel side, we
simply add a wrapper in perf tool to call midr_is_cpu_model_range().

When introduce is_target_midr_in_range_list() in kernel's cputype.h,
if no consumers in kernel use it and only useful for perf tool, then
it is unlikely to be accepted.

I think all of this is just working around the problem that
asm/cputype.h was never intended to be used in userspace. Likewise with
the other headers that we copy into tools/.

If there are bits that we *want* to share with tools/, let's factor that
out. The actual MIDR values are a good candidate for that -- we can
follow the same approach as with sysreg-defs.h.

Thanks for suggestion, Mark.

It makes sense to me for extracting MIDR and sharing between kernel and
tools/. I have created a task for following up the refactoring.

Other than that, I think that userspace should just maintain its own
infrastructure, and only pull in things from kernel sources when there's
a specific reason to. Otherwise we're just creating busywork.

I agree with the methodology.

Since Arnaldo is facing build failure when sync headers between kernel
and perf tool, to avoid long latency, let us split the refactoriing
into separate steps.

As a first step, I think my previous suggestion is valid, we can create a
header tools/perf/arch/arm64/include/cputype.h with below code:

  #include "../../../../arch/arm64/include/asm/cputype.h"

  static bool is_perf_midr_in_range_list(u32 midr,
                                         struct midr_range const *ranges)
  {
          while (ranges->model) {
                  if (midr_is_cpu_model_range(midr, ranges->model,
                                  ranges->rv_min, ranges->rv_max))
                          return true;
                  ranges++;
          }

          return false;
  }

Then, once we can generate a dynamic MIDR header file, we can use that
header and define the midr_range structure specifically in the perf.
In the end, perf can avoid to include kernel's cputype.h.

If no objection, Yicong, do you mind preparing the patch mentioned
above? Thanks!

Leo