[U-Boot] [PATCH] ARM: fdt support: Add usbethaddr as an acceptable MAC

[Tom Rini <trini@ti.com>]

On Wed, Oct 02, 2013 at 03:14:26PM -0500, Dan Murphy wrote:
> Tom
> 
> On 10/02/2013 02:19 PM, Tom Rini wrote:
> > On Wed, Oct 02, 2013 at 02:00:15PM -0500, Dan Murphy wrote:
> >
> >> A board that has a USB ethernet device only may set the usbetheraddr
> >> and not the ethaddr.
> >> ethaddr will be the default MAC address that is chosen and if that
> >> is not populated then the usbethaddr is looked at.  If neither are set
> >> then then device tree blob is not modified.
> >>
> >> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> >> ---
> >>  common/fdt_support.c |   12 +++++++++++-
> >>  1 file changed, 11 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/common/fdt_support.c b/common/fdt_support.c
> >> index b034c98..fef7e60 100644
> >> --- a/common/fdt_support.c
> >> +++ b/common/fdt_support.c
> >> @@ -450,8 +450,18 @@ void fdt_fixup_ethernet(void *fdt)
> >>  	if (node < 0)
> >>  		return;
> >>  
> >> +	if (!getenv("ethaddr")) {
> >> +		if (getenv("usbethaddr")) {
> >> +			strcpy(mac, "usbethaddr");
> >> +		} else {
> >> +			debug("No ethernet MAC Address defined\n");
> >> +			return;
> >> +		}
> >> +	} else {
> >> +		strcpy(mac, "ethaddr");
> >> +	}
> >> +
> >>  	i = 0;
> >> -	strcpy(mac, "ethaddr");
> >>  	while ((tmp = getenv(mac)) != NULL) {
> >>  		sprintf(enet, "ethernet%d", i);
> >>  		path = fdt_getprop(fdt, node, enet, NULL);
> > The problem is we may well have both.  I think we need to re-work the
> > function slightly to be:
> > while ((tmp = getenv(mac)) != NULL) {
> >   do_fdt_fixup_ethernet_x(tmp, fdt, node, enet, i)
> > }
> > if (getenv("usbethaddr"))
> >   do_fdt_fixup_ethernet_x("usbethaddr", fdt, ...)
> >
> > Where the name of the new function, and parameter order also makes sense
> > and is complete of course.  Thanks!
> >
> 
> One issue with this approach is that we don't know which inteface in
> the dt is usb ethernet and which is not.  So correctly assigning the
> MAC to the correct inteface will be tricky.

Oh, that's true...  Maybe I should withdraw my objection, since we're
unlikely to really see both in production cases.

> But the patch is flawed in the affect is that it does not take into
> account multiple usbethaddr either.  I will rework it for this but I
> am not sure about the other.

But we don't support that either, did a quick grep before posting.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131002/cc57040c/attachment.pgp>