Re: [PATCH 10/17] bootwrapper: Add dt_set_mac_addresses().

[Segher Boessenkool <segher@kernel.crashing.org>]

>>> If the property exists in the device tree, then it should be used,=20=

>>> no?  Whether or not it exists is not for the driver to decide.
>> The property doesn't describe anything about the device;
>> it merely tells you something about what the firmware did
>> during booting.
>
> Ah, I see your point.  But how else can the bootloader tell the kernel=20=

> what MAC address to use?

It should use "local-mac-address".  Quoting:

=93local-mac-address=94 S
Standard property name to specify preassigned network address.
prop-encoded-array: Array of six bytes encoded with encode-bytes.
Specifies the 48-bit IEEE 802.3-style Media Access Control (MAC)
(as specified in ISO/IEC 8802-3 : 1993 [B3]) address assigned to
the device represented by the package, of device type =93network=94,
containing this property. The absence of this property indicates
that the device does not have a permanently assigned MAC address.

>> Just everything everywhere that mentions "mac-address" should be
>> completely and utterly eradicated :-)
>
> Are you saying that Linux should not acknowledge the existence of the=20=

> mac-address property, even though it's part of the OF spec?

Oh it can acknowledge its existence, it just has no business
using its contents.

>> And sure I understand you have to change one component at a
>> time -- seems to me uboot is the first step to fix?
>
> Depends on what you mean by a fix.  Although I understand your point=20=

> that the MAC address doesn't really belong in the device tree, I don't=20=

> see any better place for it.  So for now, I'm going on the assumption=20=

> that mac-address and local-mac-address are valid properties, so it's=20=

> just a question on *how* they should be supported.

Just use "local-mac-address", ignore "mac-address" completely,
be happy, end of world hunger.  Or something like that.

> In that context, the kernel has been updated already, and some of=20
> U-Boot has also.  Well, I'm ignoring some of the more obscure IBM=20
> systems, because I don't know anything about them.  All that's left is=20=

> 85xx, 86xx, and 5xxx, and then I can clean up the DTS files, and then=20=

> as far as I'm concerned, I'm done.

I think you're on the right track and we are talking past
each other somehow.  We'll see :-)


Segher