Messages in this thread | | | From | Guo Ren <> | Date | Fri, 7 Aug 2020 08:22:36 +0800 | Subject | Re: csky: smp_mb__after_spinlock |
| |
Hi Peter,
On Thu, Aug 6, 2020 at 3:53 AM <peterz@infradead.org> wrote: > > Hi, > > While doing an audit of smp_mb__after_spinlock, I found that csky > defines it, why? > > CSKY only has smp_mb(), it doesn't override __atomic_acquire_fence or > otherwise special cases it's atomic*_acquire() primitives. It has an > explicit smp_mb() in its arch_spin_lock().
Yes, csky didn't implement ACQUIRE/RELEASE in spinlock.h. So it is a redundant and side-effect wrong macro, we should remove it to fixup.
TODO: - implement csky's ACQUIRE/RELEASE barrier
> Also, why have two implementations of all the locking?
I just kept my baby's codes :P. Now, we could remove it and just keep the ticket's one.
BTW, I want to change the spinlock to qspinlock, but csky only has 32-bit atomic operation in hardware.
Any plan to deal with this in spinlock?
Maybe for the embedded scenario, qspinlock seems a bit heavy, are any tickets-like comm spinlock infrastructures in the plan?
-- Best Regards Guo Ren
ML: https://lore.kernel.org/linux-csky/
| |