linux-kernel - Re: RFC: Platform data for onboard USB assets

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 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201103172333.01474.arnd@arndb.de>
Date:	Thu, 17 Mar 2011 23:33:01 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Greg KH <greg@...ah.com>, Grant Likely <grant.likely@...retlab.ca>,
	devicetree-discuss@...ts.ozlabs.org
Cc:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Nicolas Pitre <nicolas.pitre@...aro.org>,
	andy.green@...aro.org, Linux USB list <linux-usb@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: RFC: Platform data for onboard USB assets

On Thursday 17 March 2011 22:47:36 Greg KH wrote:
> > > Patches to fix this, for this specific PandaBoard controller are gladly
> > > accepted.  What's odd is this is explicitly a Linux development board,
> > > so you would think that this could have been caught, and fixed, in the
> > > hardware a long time ago, right?
> > 
> > The way everyone resolves this stuff is by patching their kernel
> > locally.
> 
> Well, that means that the device tree work is going to be useful here,
> right?  :)

I like the idea. Let's make this the first use case where a lot of
people will want to have the device tree on ARM. The patch to the
driver to check for a mac-address property is trivial, and we
can probably come up with a decent way of parsing the device
tree for USB devices, after all there is an existing spec for
it (http://playground.sun.com/1275/bindings/usb/usb-1_0.ps).

	Arnd

8<------
[PATCH] net/smscx5xx: demonstrate use of device tree for mac address

This takes the MAC address for smsc75xx/smsc95xx USB network devices
from a the device tree. This is required to get a usable persistent
address on the popular beagleboard, whose hardware designers
accidentally forgot that an ethernet device really requires an a
MAC address to be functional.

The smsc75xx and smsc95xx drivers are just two copies of the
same code, so better fix both.

Not tested!

Signed-off-by: Arnd Bergmann <arnd.bergmann@...aro.org>

diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
index 753ee6e..0420209 100644
--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -29,6 +29,7 @@
 #include <linux/crc32.h>
 #include <linux/usb/usbnet.h>
 #include <linux/slab.h>
+#include <linux/of_device.h>
 #include "smsc75xx.h"
 
 #define SMSC_CHIPNAME			"smsc75xx"
@@ -658,6 +659,8 @@ static int smsc75xx_ioctl(struct net_device *netdev, struct ifreq *rq, int cmd)
 
 static void smsc75xx_init_mac_address(struct usbnet *dev)
 {
+	void *address;
+
 	/* try reading mac address from EEPROM */
 	if (smsc75xx_read_eeprom(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
 			dev->net->dev_addr) == 0) {
@@ -669,6 +672,13 @@ static void smsc75xx_init_mac_address(struct usbnet *dev)
 		}
 	}
 
+	address = of_get_property(dev->udev->dev.of_node,
+				  "local-mac-address", NULL);
+	if (address) {
+		memcpy(dev->net->dev_addr, address, ETH_ALEN);
+		return;
+	}
+
 	/* no eeprom, or eeprom values are invalid. generate random MAC */
 	random_ether_addr(dev->net->dev_addr);
 	netif_dbg(dev, ifup, dev->net, "MAC address set to random_ether_addr");
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index bc86f4b..74585fb 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -29,6 +29,7 @@
 #include <linux/crc32.h>
 #include <linux/usb/usbnet.h>
 #include <linux/slab.h>
+#include <linux/of_device.h>
 #include "smsc95xx.h"
 
 #define SMSC_CHIPNAME			"smsc95xx"
@@ -639,6 +640,8 @@ static int smsc95xx_ioctl(struct net_device *netdev, struct ifreq *rq, int cmd)
 
 static void smsc95xx_init_mac_address(struct usbnet *dev)
 {
+	void *address;
+
 	/* try reading mac address from EEPROM */
 	if (smsc95xx_read_eeprom(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
 			dev->net->dev_addr) == 0) {
@@ -649,6 +652,13 @@ static void smsc95xx_init_mac_address(struct usbnet *dev)
 		}
 	}
 
+	address = of_get_property(dev->udev->dev.of_node,
+				  "local-mac-address", NULL);
+	if (address) {
+		memcpy(dev->net->dev_addr, address, ETH_ALEN);
+		return;
+	}
+
 	/* no eeprom, or eeprom values are invalid. generate random MAC */
 	random_ether_addr(dev->net->dev_addr);
 	netif_dbg(dev, ifup, dev->net, "MAC address set to random_ether_addr\n");
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/