Linus Torvalds's on April 6, 2019 1:50 am: > On Fri, Apr 5, 2019 at 4:01 AM Will Deacon <will.deacon@xxxxxxx> wrote: >> >> mmiowb() is now implied by spin_unlock() on architectures that require >> it, so there is no reason to call it from driver code. This patch was >> generated using coccinelle: >> >> @mmiowb@ >> @@ >> - mmiowb(); > > So I love the patch series, and think we should just do it, but I do > wonder if some of the drivers involved end up relying on memory > ordering things (store_release -> load_aquire) and IO ordering rather > than using locking... Hopefully the convention that smp_ prefix does not work for MMIO ordering helps there. Drivers relying on that would be broken today on powerpc, at least. > Wouldn't such use now be broken on ia64 SN platforms? Do we care? Hopefully not too much, what changed since last thread? :) > So it might be worth noting that a lot of the mmiowb()s here weren't > paired with spin_unlock? I repeat myself, but the correct change is for ia64 to #define wmb to mmiowb, then nothing is silently broken, nothing has to be noted, and nobody has to care. The ia64/sn2 platform will run a little slower that's all. But deliberately breaking sn2 I guess is implicitly acknowledging the same end result that I wanted, so fine. I think it might be an idea to remove all the mmiowb() that obviously come before spin_unlock in one big patch, but then submit the rest individually to driver maintainers. I could do that rather than ask more work from Will, if he and you agree. Thanks, Nick
