On Wed, 2010-09-01 at 14:38 -0700, David Miller wrote:

From: Ben Hutchings <redacted>
Date: Tue, 31 Aug 2010 01:15:33 +0100

quoted

vortex_ioctl() was grabbing vortex_private::lock around its call to
generic_mii_ioctl().  This is no longer necessary since there are more
specific locks which the mdio_{read,write}() functions will obtain.
Worse, those functions do not save and restore IRQ flags when locking
the MII state, so interrupts will be enabled when generic_mii_ioctl()
returns.

Since there is currently no need for any function to call
mdio_{read,write}() while holding another spinlock, do not change them
to save and restore IRQ flags but remove the specification of ordering
between vortex_private::lock and vortex_private::mii_lock.

Signed-off-by: Ben Hutchings <redacted>
---
I've now borrowed a card to test 3c59x on.  I've seen another regression
reported <http://bugs.debian.org/586967> after my locking changes, which
I can't reproduce.

I think the lock is necessary, in some form.

Nothing otherwise protects vp->mii, which is accessed and modified by
not just this ioctl, but also ethtool operation calls.

So we can't apply your patch as-is.

Hmm, yes, I forgot that mii caches information in struct mii_if_info.
Let me rethink this.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.