Thread (16 messages) 16 messages, 6 authors, 2025-06-18

Re: perf usage of arch/arm64/include/asm/cputype.h

From: Leo Yan <leo.yan@arm.com>
Date: 2025-06-18 13:02:56
Also in: lkml

On Wed, Jun 18, 2025 at 07:51:03PM +0800, Yicong Yang wrote:

[...]
quoted
quoted
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.
Yes. So Mark's suggestion is reasonable that we can do refactoring first
to avoid syncing header.

[...]
quoted
@Yicong, could you confirm if you proceed to refactor the MIDR? thanks!
please feel free to take this over.
Thanks a lot for confirmation!  And thanks for working on the reported
issue.
quoted
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.
I expect tools/arch/arm64/include/asm/cputype.h will be removed, and
a generated header (something like sys-midr.h) for MIDR refactoring.
If this is true, then we need to take care kselftest.

Thanks,
Leo
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help