| Message ID | 20180427150848.12075-1-pure.logic@nexus-software.ie |
|---|---|
| Headers | show |
| Series | Fixup set_bit/clear_bit definition and usage | expand |
Hi Bryan, On Fri, Apr 27, 2018 at 11:08 PM, Bryan O'Donoghue <pure.logic@nexus-software.ie> wrote: > Following on from a discussion with Marek and Lukasz re: a namespace > collision with set_bit and clear_bit in f_mass_storage, I noticed some > inconsistencies in the definition and usage of PLATFORM__SET_BIT and > PLATFORM__CLEAR_BIT as well as a similar use of __set_bit in the composite > USB gadget driver. > > __set_bit is lock-prefixed on x86 whereas set_bit is not and the analog > driver in upstream Linux does set_bit() not __set_bit(). > I am confused. So this changes enables x86's own __set_bit which is lock-prefixed. But you are saying the upstream Linux is using set_bit which is not lock-prefixed. Then this is inconsistent again. > This series addresses all of those inconsistencies. > > There are some usages of __set_bit() but those are in SoC specific GPIO > code-paths and therefore don't really need to change IMO. > > Bryan O'Donoghue (9): > x86: Define PLATFORM__SET_BIT for generic_set_bit() > riscv: Define PLATFORM__SET_BIT for generic_set_bit() > riscv: : Define PLATFORM__CLEAR_BIT for generic_clear_bit() > nios2: Define PLATFORM__SET_BIT for generic_set_bit() > nios2: : Define PLATFORM__CLEAR_BIT for generic_clear_bit() > nds32: Define PLATFORM__SET_BIT for generic_set_bit() > nds2: : Define PLATFORM__CLEAR_BIT for generic_clear_bit() > usb: f_mass_storage: Fix set_bit and clear_bit usage > usb: composite convert __set_bit to generic_set_bit > > arch/nds32/include/asm/bitops.h | 4 ++++ > arch/nios2/include/asm/bitops/non-atomic.h | 4 ++++ > arch/riscv/include/asm/bitops.h | 4 ++++ > arch/x86/include/asm/bitops.h | 2 ++ > drivers/usb/gadget/composite.c | 2 +- > drivers/usb/gadget/f_mass_storage.c | 25 +++------------------- > 6 files changed, 18 insertions(+), 23 deletions(-) > > -- Regards, Bin
On 28/04/18 00:38, Bin Meng wrote: > Hi Bryan, > > On Fri, Apr 27, 2018 at 11:08 PM, Bryan O'Donoghue > <pure.logic@nexus-software.ie> wrote: >> Following on from a discussion with Marek and Lukasz re: a namespace >> collision with set_bit and clear_bit in f_mass_storage, I noticed some >> inconsistencies in the definition and usage of PLATFORM__SET_BIT and >> PLATFORM__CLEAR_BIT as well as a similar use of __set_bit in the composite >> USB gadget driver. >> >> __set_bit is lock-prefixed on x86 whereas set_bit is not and the analog >> driver in upstream Linux does set_bit() not __set_bit(). >> > > I am confused. So this changes enables x86's own __set_bit which is > lock-prefixed. No sorry Bin, It's the other way around. Let me reword this for you.. /** * set_bit - Atomically set a bit in memory * @nr: the bit to set * @addr: the address to start counting from * * This function is atomic and may not be reordered. See __set_bit() * if you do not require the atomic guarantees. * Note that @nr may be almost arbitrarily large; this function is not * restricted to acting on a single-word quantity. */ static __inline__ void set_bit(int nr, volatile void * addr) { __asm__ __volatile__( LOCK_PREFIX "btsl %1,%0" :"=m" (ADDR) :"Ir" (nr)); } /** * __set_bit - Set a bit in memory * @nr: the bit to set * @addr: the address to start counting from * * Unlike set_bit(), this function is non-atomic and may be reordered. * If it's called on the same region of memory simultaneously, the effect * may be that only one operation succeeds. */ static __inline__ void __set_bit(int nr, volatile void * addr) { __asm__( "btsl %1,%0" :"=m" (ADDR) :"Ir" (nr)); }