[ath9k-devel] [RFC v2] Serialization of IO

[Luis R. Rodriguez <lrodriguez@atheros.com>]

So I've gone back to the drawing board, and reviewed this issue
as thoroughly as I can. The issue is PCI reads/writes can overlap
with each other (not just writes). This shouldn't generally be an
issue but if some reads take a while, for example, there could be
another read/write on its way on another CPU and at least for our
PCI 11n devices that will make them angry. Some PCI hosts don't seem
to do this but some others do. It should be noted this issue is not
present on our pre-802.11n devices or our new 11n PCI-express
devices.

So with clarified, here's a second attempt at serialization.
The first patch wasn't doing anything because we never initialized
ah->config.serialize_regmode. We do that now only on non-UP systems.
The last patch in the series is perhaps overkill -- but it would deal
with rare case of a UP system coming up and you hotplugging a second
CPU later. It may also help with suspend, but don't quote me on that
yet.

Anyway, here's the latest stab at it:

http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/ath9k/2009-02-11/serialization-v2.patch

This applies against today's wireless-testing/compat-wireless updates.

Please test and let me know if ath9k with PCI devices on HT/Multi-CPU
issues are corrected by it.

Known issue: ping flood in a terminal makes it painful to come back.

I've been trying to look for a more neater way to guarantee serialization
but so far this is what I have. I do wonder, for example, if some of
the atomic.h (atomic_inc_and_test()) stuff may let us use it to somehow
serialize CPU entry into a read/write. Although its not designed for it
may be worth considering. I also some of the most evil code I've seen
lately on drivers/pci/quirks.c and did wonder if there was a fix we can
re-use through there but didn't see anything. If you know have any other
ideas please let me know.

  Luis