lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 11 Jul 2007 11:58:08 +0100
From:	Ben Dooks <ben@...ff.org>
To:	Linux netdev <netdev@...r.kernel.org>
Subject: ethtool locking

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@...ff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists