On Fri, 21 Jun 2024, Jiaxun Yang wrote: > > That might do in the interim as a sanity check, however ultimately the > > sole reason these <asm/mach-*/cpu-feature-overrides.h> exist (and the > > `cpu_has_llsc' setting there) is so that a dynamic check at run time is > > avoided where the result is known from elsewhere beforehand anyway, and > > your change effectively supersedes the overrides, and therefore they need > > to be removed. > > > No, overrides are still valid if platform did CPU_MAY_HAVE_LLSC, this is at > least valid for R10000 systems (IP28 decided to opt-out from llsc somehow), > ATH25 (platform made assumption on IP version shipped with CPU), cavium > octeon (platform decided to opt-out llsc for non-SMP build). I'm not confident > with handling them all in Kconfig so I think the best approach so far is to do > build time assertion. No, CPU_MAY_HAVE_LLSC is the dynamic case, in which case you need to run verification at run time and access the result via the CPU feature vector. If you insist that you need a static override in this case, then you've got your CPU_MAY_HAVE_LLSC setting wrong, it should be either CPU_HAS_LLSC or nil, according to what <asm/mach-*/cpu-feature-overrides.h> currently sets for the platform in question. Whatever is set statically there at build time can be reproduced in Kconfig. Going through platforms should be easy if not a bit tedious, but that's the cost you sometimes need to pay for progress. Maciej
