[PATCH 2/5] arm: preserve ATAGS in /chosen/atags in the Device Tree

Thomas Petazzoni thomas.petazzoni at free-electrons.com
Fri Jun 7 13:16:51 EDT 2013

Dear Jason Cooper,

On Fri, 7 Jun 2013 10:32:49 -0400, Jason Cooper wrote:

> > Well, I don't think what you say here is really fair. Before the DT was
> > in place, unless I missed it, there was no standard way of letting the
> > bootloader pass MAC addresses to the kernel. And Marvell's development
> > on those Armada 370/XP platforms predates the introduction of the
> > Device Tree in the Linux kernel (the code we have originally been give
> > was a 2.6.3x), so it's really not their fault to not have a DT-capable
> > bootloader at this point.
> To be accurate, I think Nico is referring to the fact that Marvell
> assigned their own ATAG without going through Russell.

Right, that's true.

> However, just like mach-types, are we assigning any new atags?  Can we
> consider them deprecated?  If so, that changes the game.  Then what
> Thomas is proposing is a "legacy compatibility" patch, as opposed to a
> hole vendors can use to do their own thing.
> We could add Arnd's suggestion of a time bomb on the common code in
> atags_to_fdt.c to prevent mis-use.
> I'm not 100% convinced of this, and I actually tend to agree with Nico
> here, but I'd also like to find a workable solution.

I perfectly understand Nico and Russell concerns, for sure. But I'd
also like to find a workable solution:
 * Passing the MAC address on the kernel command line is not something
   that the network maintainer likes. See
   http://lists.openwall.net/netdev/2011/11/17/82 and Dave Miller's
   answer http://lists.openwall.net/netdev/2011/11/17/83.

 * Parsing the U-Boot environment is really not easy. How does the
   kernel know where this environment is located? What if another
   bootloader than U-Boot is used? Reading the U-Boot environment from
   the kernel sounds clunky.

Best regards,

Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.

More information about the linux-arm-kernel mailing list