netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* net/eth/ibmveth: Fixup retrieval of MAC address
@ 2013-05-02  1:35 Benjamin Herrenschmidt
  2013-05-03 16:30 ` Ben Hutchings
  0 siblings, 1 reply; 3+ messages in thread
From: Benjamin Herrenschmidt @ 2013-05-02  1:35 UTC (permalink / raw)
  To: netdev; +Cc: David Miller, linuxppc-dev, David Gibson

Some ancient pHyp versions used to create a 8 bytes local-mac-address
property in the device-tree instead of a 6 bytes one for veth.

The Linux driver code to deal with that is an insane hack which also
happens to break with some choices of MAC addresses in qemu by testing
for a bit in the address rather than just looking at the size of the
property.

Sanitize this by doing the latter instead.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: <stable@vger.kernel.org>
---

I CC'ed stable bcs I'd like to switch qemu/kvm to 6-bytes properties as
soon as possible. Unfortunately doing so breaks the horrible hack unless
qemu has the right magic bit in the MAC which it may or may not have...

diff --git a/drivers/net/ethernet/ibm/ibmveth.c b/drivers/net/ethernet/ibm/ibmveth.c
index c859771..579a03e 100644
--- a/drivers/net/ethernet/ibm/ibmveth.c
+++ b/drivers/net/ethernet/ibm/ibmveth.c
@@ -1324,7 +1324,7 @@ static const struct net_device_ops ibmveth_netdev_ops = {
 
 static int ibmveth_probe(struct vio_dev *dev, const struct vio_device_id *id)
 {
-	int rc, i;
+	int rc, i, mac_len;
 	struct net_device *netdev;
 	struct ibmveth_adapter *adapter;
 	unsigned char *mac_addr_p;
@@ -1334,11 +1334,19 @@ static int ibmveth_probe(struct vio_dev *dev, const struct vio_device_id *id)
 		dev->unit_address);
 
 	mac_addr_p = (unsigned char *)vio_get_attribute(dev, VETH_MAC_ADDR,
-							NULL);
+							&mac_len);
 	if (!mac_addr_p) {
 		dev_err(&dev->dev, "Can't find VETH_MAC_ADDR attribute\n");
 		return -EINVAL;
 	}
+	/* Workaround for old/broken pHyp */
+	if (mac_len == 8)
+		mac_addr_p += 2;
+	if (mac_len != 6) {
+		dev_err(&dev->dev, "VETH_MAC_ADDR attribute wrong len %d\n",
+			mac_len);
+		return -EINVAL;
+	}
 
 	mcastFilterSize_p = (unsigned int *)vio_get_attribute(dev,
 						VETH_MCAST_FILTER_SIZE, NULL);
@@ -1363,17 +1371,6 @@ static int ibmveth_probe(struct vio_dev *dev, const struct vio_device_id *id)
 
 	netif_napi_add(netdev, &adapter->napi, ibmveth_poll, 16);
 
-	/*
-	 * Some older boxes running PHYP non-natively have an OF that returns
-	 * a 8-byte local-mac-address field (and the first 2 bytes have to be
-	 * ignored) while newer boxes' OF return a 6-byte field. Note that
-	 * IEEE 1275 specifies that local-mac-address must be a 6-byte field.
-	 * The RPA doc specifies that the first byte must be 10b, so we'll
-	 * just look for it to solve this 8 vs. 6 byte field issue
-	 */
-	if ((*mac_addr_p & 0x3) != 0x02)
-		mac_addr_p += 2;
-
 	adapter->mac_addr = 0;
 	memcpy(&adapter->mac_addr, mac_addr_p, 6);
 

^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: net/eth/ibmveth: Fixup retrieval of MAC address
  2013-05-02  1:35 net/eth/ibmveth: Fixup retrieval of MAC address Benjamin Herrenschmidt
@ 2013-05-03 16:30 ` Ben Hutchings
  2013-05-03 21:17   ` Benjamin Herrenschmidt
  0 siblings, 1 reply; 3+ messages in thread
From: Ben Hutchings @ 2013-05-03 16:30 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: netdev, David Miller, linuxppc-dev, David Gibson

On Thu, 2013-05-02 at 11:35 +1000, Benjamin Herrenschmidt wrote:
> Some ancient pHyp versions used to create a 8 bytes local-mac-address
> property in the device-tree instead of a 6 bytes one for veth.
> 
> The Linux driver code to deal with that is an insane hack which also
> happens to break with some choices of MAC addresses in qemu by testing
> for a bit in the address rather than just looking at the size of the
> property.
> 
> Sanitize this by doing the latter instead.
[...]
> @@ -1334,11 +1334,19 @@ static int ibmveth_probe(struct vio_dev *dev, const struct vio_device_id *id)
>  		dev->unit_address);
>  
>  	mac_addr_p = (unsigned char *)vio_get_attribute(dev, VETH_MAC_ADDR,
> -							NULL);
> +							&mac_len);
>  	if (!mac_addr_p) {
>  		dev_err(&dev->dev, "Can't find VETH_MAC_ADDR attribute\n");
>  		return -EINVAL;
>  	}
> +	/* Workaround for old/broken pHyp */
> +	if (mac_len == 8)
> +		mac_addr_p += 2;
> +	if (mac_len != 6) {

Missing 'else' before the second if?

> +		dev_err(&dev->dev, "VETH_MAC_ADDR attribute wrong len %d\n",
> +			mac_len);
> +		return -EINVAL;
> +	}
[...]

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: net/eth/ibmveth: Fixup retrieval of MAC address
  2013-05-03 16:30 ` Ben Hutchings
@ 2013-05-03 21:17   ` Benjamin Herrenschmidt
  0 siblings, 0 replies; 3+ messages in thread
From: Benjamin Herrenschmidt @ 2013-05-03 21:17 UTC (permalink / raw)
  To: Ben Hutchings; +Cc: netdev, David Miller, linuxppc-dev, David Gibson

On Fri, 2013-05-03 at 17:30 +0100, Ben Hutchings wrote:
> > +	/* Workaround for old/broken pHyp */
> > +	if (mac_len == 8)
> > +		mac_addr_p += 2;
> > +	if (mac_len != 6) {
> 
> Missing 'else' before the second if?

Absolutely... oops :-) I couldn't find a version of pHyp with the wrong
property to test with. I suppose I could hack it up in OFW before boot.

I'll fix that and respin, sorry about that.

Cheers,
Ben.

> > +		dev_err(&dev->dev, "VETH_MAC_ADDR attribute wrong len %d\n",
> > +			mac_len);
> > +		return -EINVAL;
> > +	}
> [...]
> 

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2013-05-03 21:17 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-05-02  1:35 net/eth/ibmveth: Fixup retrieval of MAC address Benjamin Herrenschmidt
2013-05-03 16:30 ` Ben Hutchings
2013-05-03 21:17   ` Benjamin Herrenschmidt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).