On Fri, Dec 06, 2019 at 06:29:39PM +0100, Thomas Renninger wrote: > On Friday, December 6, 2019 5:58:03 PM CET Mark Rutland wrote: > > On Fri, Dec 06, 2019 at 05:24:18PM +0100, Thomas Renninger wrote: > > For arm64 we already expose the MIDR and REVIDR register values under > > /sys/devices/system/cpu/cpu*/regs/identification, and that's the bulk of > > the useful information above > > I'd like to come up with an extra CONFIG which parses: > > arch/arm64/include/asm/cputype.h: > > #define ARM_CPU_PART_AEM_V8 0xD0F > #define ARM_CPU_PART_FOUNDATION 0xD00 > #define ARM_CPU_PART_CORTEX_A57 0xD07 > #define ARM_CPU_PART_CORTEX_A72 0xD08 > > and > > #define ARM_CPU_IMP_ARM 0x41 > #define ARM_CPU_IMP_APM 0x50 > #define ARM_CPU_IMP_CAVIUM 0x43 > #define ARM_CPU_IMP_BRCM 0x42 > #define ARM_CPU_IMP_QCOM 0x51 > #define ARM_CPU_IMP_NVIDIA 0x4E > > and converts the defines to strings, same as here: A similar approach for /proc/cpuinfo has been NAK'd repeatedly in the past. While some arguments against that don't apply here, I don't think that we want to have to maintain an ever-growing list of strings that end up being ABI which we cannot manage in a forwards-compatible manner. When it is necessary to reliably and unambiguously identify a CPU, it'll always end up being necessary to look at the MIDR (and possibly REVIDR), so that's what applications should always do, and it's what users will necessarily have to do when the kernel doesn't have a string for a CPU, as is the case for all existing kernels. I don't think that in-kernel stringification of the MIDR is a good idea, and I would suggest not wasting your time on that. Thanks, Mark.
