[PATCH] ARM: atags: add support for Marvell's u-boot
Jason Cooper
jason at lakedaemon.net
Mon Jun 3 14:26:09 EDT 2013
On Mon, Jun 03, 2013 at 02:14:37PM -0400, Jason Cooper wrote:
> On Mon, Jun 03, 2013 at 07:56:29PM +0200, Willy Tarreau wrote:
> > Hi Russell,
> >
> > On Mon, Jun 03, 2013 at 06:10:18PM +0100, Russell King - ARM Linux wrote:
> > > You know, my reaction to this is to nack it because:
> > >
> > > (a) Marvell didn't talk to me about adding a new tag.
> > > (b) There is an established precident that we do not pass MAC addresses
> > > to the kernel in this way (such attempts have been rejected in the
> > > past.)
> > > (c) It goes completely against the design spirit of ATAGs by combining
> > > many different types and instances of information into one tag.
> > > (d) It picks a tag ID without understanding how tag IDs are allocated.
> > > (the idea is 0x41NNNNVV where NNNN = machine ID for machine specific
> > > tags.)
> > >
> > > Everyone who has gone around extending ATAG stuff has made exactly the
> > > same mistakes time and time again - mostly stemming from the fact that
> > > no one wants to talk to me up front.
> > >
> > > So, this is another NACK.
> >
> > I understand your points, but then what could we do to get our devices
> > to have properly working ethernet interfaces ? These devices have already
> > been sold, and from what I've seen they've been using this ID since at
> > least the Kirkwood devices.
> >
> > I found no other way to get the MAC address once the system is booted.
> > I would have no problem having some board-spec code locate the atags
> > and set the MAC, but it looks like the information is lost very early
> > and is not available anymore soon after the boot (or at least I couldn't
> > find it anywhere else).
> >
> > It's really not with happiness that I had to add this part to the ATAGs,
> > but because I didn't find another solution :-(
>
> Please take a look at Sebastian's approach, it's currently a wip:
>
> ARM: kirkwood: proper retain MAC address workaround on DT ethernet
>
> The discussion following that patch should give you some good ideas.
Gah, here's the direct link to the patch:
https://lkml.org/lkml/2013/5/22/541
hth,
Jason.
More information about the linux-arm-kernel
mailing list