ethtool locking

ethtool locking

[Ben Dooks]

I am currently upgrading the DM9000 network driver to support
ethtool for items such as controlling the MII interface and
have the following question about locking with the ethtool
interface:

Most devices use an overall spinlock when changing the settings
such as in the 8139too.c driver:

static int rtl8139_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
{
	struct rtl8139_private *np = netdev_priv(dev);
	int rc;
	spin_lock_irq(&np->lock);
	rc = mii_ethtool_sset(&np->mii, cmd);
	spin_unlock_irq(&np->lock);
	return rc;
}

In the case of the DM9000, the phy read and write code
already has a spinlock in for hardware access.

Do I need any more locking for the MII calls other than
what is provided by the lower layer (IE, do these calls
need locking against anything else?)

-- 
Ben (ben@fluff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

Re: ethtool locking

[Stephen Hemminger]

On Wed, 11 Jul 2007 11:58:08 +0100
Ben Dooks <ben@fluff.org> wrote:

> I am currently upgrading the DM9000 network driver to support
> ethtool for items such as controlling the MII interface and
> have the following question about locking with the ethtool
> interface:
> 
> Most devices use an overall spinlock when changing the settings
> such as in the 8139too.c driver:
> 
> static int rtl8139_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
> {
> 	struct rtl8139_private *np = netdev_priv(dev);
> 	int rc;
> 	spin_lock_irq(&np->lock);
> 	rc = mii_ethtool_sset(&np->mii, cmd);
> 	spin_unlock_irq(&np->lock);
> 	return rc;
> }
> 
> In the case of the DM9000, the phy read and write code
> already has a spinlock in for hardware access.
> 
> Do I need any more locking for the MII calls other than
> what is provided by the lower layer (IE, do these calls
> need locking against anything else?)
> 

All network API changes are currently protected by the netlink
mutex (commonly referred to as RTNL). But your device must protect
itself from any changes in settings due to interrupts from PHY.

-- 
Stephen Hemminger <shemminger@linux-foundation.org>