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