On 2025/6/18 19:24, Leo Yan wrote:

On Wed, Jun 18, 2025 at 09:52:53AM +0100, Mark Rutland wrote:

[...]

quoted

quoted

quoted

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"

Directly including the kernel header introduces the very fragility that
having a copy was intended to avoid. NAK to that.

My suggestion is not to include the kernel header, nor to modify the
copy header. :)

Instead, I suggested creating a new header within the perf tool (under
perf's arm64 folder) and then include the copy header in tools:

  tools/arch/arm64/include/asm/cputype.h

sorry for the misunderstood.:(
in this way we still have the divergency in the long term and as a workaround
this works same if we partly update the tools/arch/arm64/include/asm/cputype.h
with only necessary MIDR updates and keep is_midr_in_range_list() unchanged.

quoted

I've replied to the same effect Yicong's patch [1,2].

If we want to share headers between userspace and kernel, we should
refactor those headers such that this is safe by construction.

There is no need to update the userspace headers just because the kernel
headers have changed, so the simple solution in the short term is to
suppress the warning from check-headers.sh.

Sure, makes sense for me.

@Arnaldo, as Mark suggested, do you want me to send a patch to remove
cputype.h checking in check-headers.sh or it is fine to keep the warning
until finish the header refactoring?

@Yicong, could you confirm if you proceed to refactor the MIDR? thanks!

please feel free to take this over.

Just note, I searched tools folder and found kselftest also uses the
cputype.h header. The refactoring should not break the files below.

they shouldn't affected. I did a kselftest build test with my latest patch
and they were not affected.

thanks.

$ git grep cputype.h
perf/check-headers.sh:check arch/arm64/include/asm/cputype.h '-I "^#include [<\"]\(asm/\)*sysreg.h"'
perf/util/arm-spe.c:#include "../../arch/arm64/include/asm/cputype.h"
testing/selftests/kvm/arm64/psci_test.c:#include <asm/cputype.h>
testing/selftests/kvm/lib/arm64/vgic.c:#include <asm/cputype.h>

Thanks,
Leo

quoted

[1] https://lore.kernel.org/linux-arm-kernel/dc5afc5c-060c-8bcb-c3a7-0de49a7455fb@huawei.com/T/#m23dfbea6af559f3765d89b9d8427213588871ffd (local)
[2] https://lore.kernel.org/linux-arm-kernel/dc5afc5c-060c-8bcb-c3a7-0de49a7455fb@huawei.com/T/#m6acbfa00002af8ee791266ea86a58f8f994ed710 (local)

Mark.

quoted

  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

.