[U-Boot] [PATCH] net: axi_ethernet: Add driver to u-boot

From: Mike Frysinger <vapier@gentoo.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] net: axi_ethernet: Add driver to u-boot
Date: Tue, 1 Mar 2011 04:10:39 -0500	[thread overview]
Message-ID: <201103010410.39867.vapier@gentoo.org> (raw)
In-Reply-To: <4D6CB258.40308@monstr.eu>

On Tuesday, March 01, 2011 03:46:16 Michal Simek wrote:
> Mike Frysinger wrote:
> > On Tuesday, March 01, 2011 03:19:12 Michal Simek wrote:
> >>>> +static void setup_mac(struct eth_device *dev)
> >>>> +{
> >>>> +	/* Set the MAC address */
> >>>> +	int val = ((dev->enetaddr[3] << 24) | (dev->enetaddr[2] << 16) |
> >>>> +		(dev->enetaddr[1] << 8) | (dev->enetaddr[0]));
> >>>> +	out_be32(dev->iobase + XAE_UAW0_OFFSET, val);
> >>>> +
> >>>> +	val = (dev->enetaddr[5] << 8) | dev->enetaddr[4] ;
> >>>> +	val |= in_be32(dev->iobase + XAE_UAW1_OFFSET)
> >>>> +						& ~XAE_UAW1_UNICASTADDR_MASK;
> >>>> +	out_be32(dev->iobase + XAE_UAW1_OFFSET, val);
> >>>> +}
> >>>> ...
> >>>> +static int axiemac_init(struct eth_device *dev, bd_t * bis)
> >>>> +{
> >>>> ...
> >>>> +	setup_mac(dev);
> >>> 
> >>> this should be moved to eth_device.write_hwaddr in the initialize
> >>> function. then the common layers will call setup_mac for you as needed.
> >> 
> >> I am not going to use write_hwaddr function because axi emac needs some
> >> initialization before you can write a mac addr that's why I will keep it
> >> in the same location as is.
> > 
> > please add explicit comments to the setup_mac() func then so someone else
> > doesnt go changing things without taking this into consideration first
> 
> No problem to write it.
> 
> I have experience with several network IPs but I think less amount than
> you.

i think you unduly credit me with more experience than i actually have

> But anyway I think it is common that device must be in proper state
> to be able to setup mac for most of them.
>  From my simple test I see that dev->write_hwaddr is called before
> dev->init which looks weird.

i dont think this is weird ... usually the MAC address is simply memory mapped 
storage, so the state of the EMAC controller itself doesnt matter.  you can 
peek/poke the contents of that MAC address storage at any time.

but i dont know what weirdness your controller has in place to make this not 
work too.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110301/8c3eae25/attachment.pgp 