Hi Peter, On Thu, Aug 6, 2020 at 3:53 AM <peterz@xxxxxxxxxxxxx> 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/
