Re: [PATCH v2 2/4] MIPS: Introduce config options for LLSC availability

["Jiaxun Yang" <jiaxun.yang@flygoat.com>]

在2024年6月21日六月 下午2:57，Maciej W. Rozycki写道：
> On Fri, 21 Jun 2024, Jiaxun Yang wrote:
>
>> >  I think this ought not to be done in two places independently and the 
>> > pieces in <asm/mach-*/cpu-feature-overrides.h> need to be removed, likely 
>> > in the same change even, *however* not without double-checking whether 
>> > there is not a case among them where a platform actually has LL/SC support 
>> > disabled despite the CPU used there having architectural support for the 
>> > feature.  Otherwise we may end up with a case where a platform has LL/SC 
>> > support disabled via its <asm/mach-*/cpu-feature-overrides.h> setting and 
>> > yet we enable ARCH_SUPPORTS_ATOMIC_RMW or ARCH_HAVE_NMI_SAFE_CMPXCHG for 
>> > it via Kconfig.
>> 
>> IMO it's necessary for platforms who know what are they doing such as ATH25,
>> which we took care in this series.
>> 
>> I'll add a build time assertion to ensure when CONFIG_CPU_HAS_LLSC is selected
>> kernel_uses_llsc is statically 1, so any incorrect overrides can be spotted
>> at build time.
>
>  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.

Does anyone reckon the reason behind opt-out LLSC for IP28? As far as I understand
there is no restriction on using LLSC after workaround being applied. If it's purely
performance reason, I think I'll need to move kernel_uses_llsc logic to Kconfig as well.

Thanks
>
>   Maciej

-- 
- Jiaxun