[PATCH v4 13/13] riscv: Add qspinlock support
Alexandre Ghiti
alex at ghiti.fr
Fri Aug 2 01:58:51 PDT 2024
On 01/08/2024 12:15, Andrew Jones wrote:
> On Thu, Aug 01, 2024 at 10:43:03AM GMT, Alexandre Ghiti wrote:
> ...
>>>> diff --git a/include/asm-generic/qspinlock.h b/include/asm-generic/qspinlock.h
>>>> index 0655aa5b57b2..bf47cca2c375 100644
>>>> --- a/include/asm-generic/qspinlock.h
>>>> +++ b/include/asm-generic/qspinlock.h
>>>> @@ -136,6 +136,7 @@ static __always_inline bool virt_spin_lock(struct qspinlock *lock)
>>>> }
>>>> #endif
>>>>
>>>> +#ifndef __no_arch_spinlock_redefine
>>> I'm not sure what's better/worse, but instead of inventing this
>>> __no_arch_spinlock_redefine thing we could just name all the functions
>>> something like __arch_spin* and then add defines for both to asm/spinlock.h,
>>> i.e.
>>>
>>> #define queued_spin_lock(l) __arch_spin_lock(l)
>>> ...
>>>
>>> #define ticket_spin_lock(l) __arch_spin_lock(l)
>>> ...
>> __arch_spin_lock() would use queued_spin_lock() so that would make an
>> "infinite recursive definition" right? And that would override the
>> "real" queued_spin_lock() implementation too.
>>
>> But maybe I missed something!
>>
> It depends on where the definition is done. It should work if the
> preprocessor expands the implementation of __arch_spin_* before
> evaluating the #define of queued_spin_*. IOW, we just need to put
> the defines after the static inline constructions.
So I have just given it a try, both qspinlock.h and ticket_spinlock.h
define arch_spin_XXXX(). That triggers a bunch of warnings.
I'll drop this suggestion as I find it harder to understand and because
of the warnings that would need the introduction of a new preprocessor
variable (or something else?). And the solution with
__no_arch_spinlock_redefine is really straightforward and lightweight.
Thanks,
Alex
>
> Thanks,
> drew
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
More information about the linux-riscv
mailing list