Re: [PATCH] tg3: fix big endian MAC address collection failure

["Matt Carlson" <mcarlson@broadcom.com>]

On Mon, Apr 13, 2009 at 11:15:16AM -0700, James Bottomley wrote:
> On Mon, 2009-04-13 at 11:00 -0700, Matt Carlson wrote:
> > Hi James.  I'd like to think about this some more before we apply it.  I
> > investigated this problem using a 5703 on a SPARC Ultra 10, and all my
> > assumptions checked out.
> 
> Um, I think you'll find the SPARC has a special routine for extracting
> the MAC address from Open Firmware, so it doesn't exercise the NVRAM
> path.

Yes, it does.  The driver moves beyond that point because the routine
fails on this system.  (It's really old and doesn't have a Broadcom LOM
on it.)

> >   I don't dispute that you and Robin are having
> > a problem.  I just don't understand where the root cause of the problem
> > is yet.  Stay tuned.
> 
> The root cause is basically that if you get the MAC from NVRAM into two
> native 32 bit words, you have to be careful about how you convert them
> to a byte stream for the MAC address.  You can't use a memcpy from the
> native number to the MAC because it's not endian invariant (it copies
> the numbers the opposite ways around on big and little endian boxes).
> 
> James

But that is exactly what the code is doing.  tg3_nvram_read_be32() will
return the data in bytestream format.  A memcpy() should be all that is
needed to transport the data to a different memory location.