Re: [PATCH] Document Linux's memory barriers [try #4]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Friday 10 March 2006 00:56, you wrote:
> 
> On Fri, 10 Mar 2006, Michael Buesch wrote:
> > 
> > So what about:
> > 
> > #define spin_lock_mmio(lock)	spin_lock(lock)
> > #define spin_unlock_mmio(lock)	do { spin_unlock(lock); mmiowb(); } while (0)
> 
> You need to put the mmiowb() inside the spinlock.

Ok, sorry. That was a typo.
I should not do more than 3 things at the same time. :)

> Yes, that is painful. But the point being that if it's outside, then when 
> somebody else gets the lock, the previous lock-owners MMIO stores may 
> still be in flight, which is what you didn't want in the first place.
> 
> Anyway, no need to make a new name for it, since you might as well just 
> use the mmiowb() explicitly. At least until this has been shown to be a 
> really common pattern (it clearly isn't, right now ;)

Ok, so maybe it is best if every device creates its own macros
for convenience (if needed => if it is a common pattern
in the scope of the driver).

Example:
#define bcm43xx_lock(bcm, flags)	spin_lock_irqsave(&(bcm)->lock, flags)
#define bcm43xx_unlock(bcm, flags)	do { mmiowb(); spin_unlock_irqrestore(&(bcm)->lock, flags); } while (0)

-- 
Greetings Michael.

Attachment: pgpMDlonTSLvG.pgp
Description: PGP signature


[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux