Re: [PATCH v4 13/13] riscv: Add qspinlock support
From: Alexandre Ghiti <alex@ghiti.fr>
Date: 2024-08-02 08:58:57
Also in:
linux-arch, linux-devicetree, linux-riscv, lkml
On 01/08/2024 12:15, Andrew Jones wrote:
On Thu, Aug 01, 2024 at 10:43:03AM GMT, Alexandre Ghiti wrote: ...quoted
quoted
quoted
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_redefineI'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@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv