mac-address vs. local-mac-address

mac-address vs. local-mac-address

[Timur Tabi]

Hi everyone,

What is the current consensus on using mac-address vs. local-mac-address in the 
device tree?  The 1275 spec says this:

"local-mac-address" Standard property name to specify preassigned network address.
"mac-address" Standard property name to specify network address last used.

I think we need to agree on some interpretation of these statements, and all the 
code should be updated to implement that interpretation.

My interpretation is that mac-address is supposed to the contain these MAC 
addresses under these circumstances:

1) If the Ethernet interface is up, it's the MAC address that is currently in use.
2) If the Ethernet interface is not up, it's the MAC address that was in use the 
last time the Ethernet interface was shut down.

In Linux, the ifconfig command is used to change the MAC address.  This command 
calls the driver's set_mac_address function, so it is the driver that sets the 
MAC address in the hardware.

In order to properly support the mac-address property, the driver must also 
update the device tree with the new MAC address.  That's the only way that 
mac-address can contain the "specify network address last used".

Linux doesn't support that.  In some cases, the actual device tree is located on 
a TFTP server, and it's only copied temporarily into RAM by U-Boot.  There's no 
way that a Linux driver can update that.

On a full-blown OF machine, the firmware does provide APIs for updating the 
device tree, and so we could support mac-address on these machines.  But U-Boot 
disappears once the kernel loads, so there is no firmware to call to update the 
device tree.

Therefore, I propose that on systems where the driver cannot update the device 
tree, the mac-address property should be absent from the device tree.  U-Boot 
should not add one, and the Linux device drivers should not reference it.

Comments?

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

Re: mac-address vs. local-mac-address

[Benjamin Herrenschmidt]

On Wed, 2007-02-07 at 15:17 -0600, Timur Tabi wrote:
> Hi everyone,
> 
> What is the current consensus on using mac-address vs. local-mac-address in the 
> device tree?  The 1275 spec says this:
> 
> "local-mac-address" Standard property name to specify preassigned network address.
> "mac-address" Standard property name to specify network address last used.
> 
> I think we need to agree on some interpretation of these statements, and all the 
> code should be updated to implement that interpretation.

It's fairly clear:

local-mac-address is what is statically set by the firwmare (comes from
EEPROM, whatever).

mac-address is really only meaningful if your firmware is
"dynamic" (real OF, uboot maybe) and was, for some reason, instructed by
the user to use a different mac address for that boot (if that feature
exist).

It's basically the mac-address that was actually used on that interface
to netboot the kernel I'd say.

> Linux doesn't support that.  In some cases, the actual device tree is located on 
> a TFTP server, and it's only copied temporarily into RAM by U-Boot.  There's no 
> way that a Linux driver can update that.

I don't understand what you mean here :-) The linux driver can perfectly
well update the in-memory copy of the device-tree, which would make it
useful in the case of a kexec to a newer kernel.

> On a full-blown OF machine, the firmware does provide APIs for updating the 
> device tree, and so we could support mac-address on these machines.  But U-Boot 
> disappears once the kernel loads, so there is no firmware to call to update the 
> device tree.

I don't understand what the firmware device-tree has to do with that...

If uboot is instructed to use a different mac-address than the
"built-in" one, it can perfectly well create that property before
getting to the kernel.

> Therefore, I propose that on systems where the driver cannot update the device 
> tree, the mac-address property should be absent from the device tree.  U-Boot 
> should not add one, and the Linux device drivers should not reference it.

"cannot update the device tree" is what makes little sense to me.

Ben.

Re: mac-address vs. local-mac-address

[Kumar Gala]

On Feb 7, 2007, at 3:32 PM, Benjamin Herrenschmidt wrote:

> On Wed, 2007-02-07 at 15:17 -0600, Timur Tabi wrote:
>> Hi everyone,
>>
>> What is the current consensus on using mac-address vs. local-mac- 
>> address in the
>> device tree?  The 1275 spec says this:
>>
>> "local-mac-address" Standard property name to specify preassigned  
>> network address.
>> "mac-address" Standard property name to specify network address  
>> last used.
>>
>> I think we need to agree on some interpretation of these  
>> statements, and all the
>> code should be updated to implement that interpretation.
>
> It's fairly clear:
>
> local-mac-address is what is statically set by the firwmare (comes  
> from
> EEPROM, whatever).
>
> mac-address is really only meaningful if your firmware is
> "dynamic" (real OF, uboot maybe) and was, for some reason,  
> instructed by
> the user to use a different mac address for that boot (if that feature
> exist).
>
> It's basically the mac-address that was actually used on that  
> interface
> to netboot the kernel I'd say.

Which means the code in fsl_soc.c is wrong in how it handles the  
precedence of gianfar:

                 mac_addr = get_property(np, "local-mac-address", NULL);
                 if (mac_addr == NULL)
                         mac_addr = get_property(np, "mac-address",  
NULL);
                 if (mac_addr == NULL) {
                         /* Obsolete */
                         mac_addr = get_property(np, "address", NULL);
                 }

should really be:

                 mac_addr = get_property(np, "mac-address", NULL);
                 if (mac_addr == NULL)
                         mac_addr = get_property(np, "local-mac- 
address", NULL);
                 if (mac_addr == NULL) {
                         /* Obsolete */
                         mac_addr = get_property(np, "address", NULL);
                 }

- k

Re: mac-address vs. local-mac-address

[Timur Tabi]

Benjamin Herrenschmidt wrote:
> On Wed, 2007-02-07 at 15:17 -0600, Timur Tabi wrote:
>> Hi everyone,
>>
>> What is the current consensus on using mac-address vs. local-mac-address in the 
>> device tree?  The 1275 spec says this:
>>
>> "local-mac-address" Standard property name to specify preassigned network address.
>> "mac-address" Standard property name to specify network address last used.
>>
>> I think we need to agree on some interpretation of these statements, and all the 
>> code should be updated to implement that interpretation.
> 
> It's fairly clear:
> 
> local-mac-address is what is statically set by the firwmare (comes from
> EEPROM, whatever).
> 
> mac-address is really only meaningful if your firmware is
> "dynamic" (real OF, uboot maybe) and was, for some reason, instructed by
> the user to use a different mac address for that boot (if that feature
> exist).
> 
> It's basically the mac-address that was actually used on that interface
> to netboot the kernel I'd say.
> 
>> Linux doesn't support that.  In some cases, the actual device tree is located on 
>> a TFTP server, and it's only copied temporarily into RAM by U-Boot.  There's no 
>> way that a Linux driver can update that.
> 
> I don't understand what you mean here :-) The linux driver can perfectly
> well update the in-memory copy of the device-tree, which would make it
> useful in the case of a kexec to a newer kernel.

That makes sense.  I don't know anything about kexec, so I didn't think there 
was any point in updating the in-memory copy.  But in this case, the driver 
should update it.

>> On a full-blown OF machine, the firmware does provide APIs for updating the 
>> device tree, and so we could support mac-address on these machines.  But U-Boot 
>> disappears once the kernel loads, so there is no firmware to call to update the 
>> device tree.
> 
> I don't understand what the firmware device-tree has to do with that...

Without a firmware device tree, there's no way to update the device tree and 
have that new tree retained over a reboot.

> If uboot is instructed to use a different mac-address than the
> "built-in" one, it can perfectly well create that property before
> getting to the kernel.

And it does, depending on which version of U-Boot.  There is debate (inside 
Freescale, at least) whether U-Boot should update mac-address or 
local-mac-address.  It sounds to me like it should update local-mac-address, and 
the DTS file shouldn't even include an entry for mac-address.

>> Therefore, I propose that on systems where the driver cannot update the device 
>> tree, the mac-address property should be absent from the device tree.  U-Boot 
>> should not add one, and the Linux device drivers should not reference it.
> 
> "cannot update the device tree" is what makes little sense to me.

If I keep my device tree on a TFTP server, which U-Boot fetches every time it 
boots the kernel, there's no way for Linux to update *that* device tree, which 
would be the only one that's important.  You mentioned kexec earlier, and that's 
fine, so the driver should update the in-memory copy.  But in my opinion, the 
in-memory copy of the device tree isn't the *real* device tree, it's just a 
temporary copy of one.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

Re: mac-address vs. local-mac-address

[Timur Tabi]

Kumar Gala wrote:

> Which means the code in fsl_soc.c is wrong in how it handles the 
> precedence of gianfar:

I agree, and this is the type of thing that we're trying to clear up.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

Re: mac-address vs. local-mac-address

[Kumar Gala]

On Feb 7, 2007, at 3:42 PM, Timur Tabi wrote:

> Benjamin Herrenschmidt wrote:
>> On Wed, 2007-02-07 at 15:17 -0600, Timur Tabi wrote:
>>> Hi everyone,
>>>
>>> What is the current consensus on using mac-address vs. local-mac- 
>>> address in the
>>> device tree?  The 1275 spec says this:
>>>
>>> "local-mac-address" Standard property name to specify preassigned  
>>> network address.
>>> "mac-address" Standard property name to specify network address  
>>> last used.
>>>
>>> I think we need to agree on some interpretation of these  
>>> statements, and all the
>>> code should be updated to implement that interpretation.
>>
>> It's fairly clear:
>>
>> local-mac-address is what is statically set by the firwmare (comes  
>> from
>> EEPROM, whatever).
>>
>> mac-address is really only meaningful if your firmware is
>> "dynamic" (real OF, uboot maybe) and was, for some reason,  
>> instructed by
>> the user to use a different mac address for that boot (if that  
>> feature
>> exist).
>>
>> It's basically the mac-address that was actually used on that  
>> interface
>> to netboot the kernel I'd say.
>>
>>> Linux doesn't support that.  In some cases, the actual device  
>>> tree is located on
>>> a TFTP server, and it's only copied temporarily into RAM by U- 
>>> Boot.  There's no
>>> way that a Linux driver can update that.
>>
>> I don't understand what you mean here :-) The linux driver can  
>> perfectly
>> well update the in-memory copy of the device-tree, which would  
>> make it
>> useful in the case of a kexec to a newer kernel.
>
> That makes sense.  I don't know anything about kexec, so I didn't  
> think there
> was any point in updating the in-memory copy.  But in this case,  
> the driver
> should update it.
>
>>> On a full-blown OF machine, the firmware does provide APIs for  
>>> updating the
>>> device tree, and so we could support mac-address on these  
>>> machines.  But U-Boot
>>> disappears once the kernel loads, so there is no firmware to call  
>>> to update the
>>> device tree.
>>
>> I don't understand what the firmware device-tree has to do with  
>> that...
>
> Without a firmware device tree, there's no way to update the device  
> tree and
> have that new tree retained over a reboot.
>
>> If uboot is instructed to use a different mac-address than the
>> "built-in" one, it can perfectly well create that property before
>> getting to the kernel.
>
> And it does, depending on which version of U-Boot.  There is debate  
> (inside
> Freescale, at least) whether U-Boot should update mac-address or
> local-mac-address.  It sounds to me like it should update local-mac- 
> address, and
> the DTS file shouldn't even include an entry for mac-address.

The problem with u-boot is that the correct way would be to use local- 
mac-address for what's compiled into u-boot and mac-address if  
someone does a 'setenv' to modify the mac address.  The question is  
anyone really going to care that much.

- k

Re: mac-address vs. local-mac-address

[Benjamin Herrenschmidt]

> Without a firmware device tree, there's no way to update the device tree and 
> have that new tree retained over a reboot.

I don't think it was ever question to update it over reboot...
mac-address is a runtime property that is lost at reboot, at least
that's my understanding of the OF behaviour. That's where your confusion
is.

Ben.

Re: mac-address vs. local-mac-address

[Timur Tabi]

Kumar Gala wrote:

> The problem with u-boot is that the correct way would be to use 
> local-mac-address for what's compiled into u-boot and mac-address if 
> someone does a 'setenv' to modify the mac address.  The question is 
> anyone really going to care that much.

I don't think the compiled-in MAC address should be used at all.

For most boards, the compiled-in option is just some random MAC address.  When 
the board is shipped, the manufacturer creates his own set of environment 
variables and overrides what's stored on flash.

I actually think that storing a MAC address in a board configuration for or a 
DTS is a bad idea, because MAC addresses are supposed to be unique for each 
Ethernet device, and storing a fixed value in a source file breaks that. 
However, that's a separate issue.  I was just trying to stress that the 
compiled-in MAC address is of no value.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

Re: mac-address vs. local-mac-address

[Kumar Gala]

On Feb 7, 2007, at 4:07 PM, Timur Tabi wrote:

> Kumar Gala wrote:
>
>> The problem with u-boot is that the correct way would be to use  
>> local-mac-address for what's compiled into u-boot and mac-address  
>> if someone does a 'setenv' to modify the mac address.  The  
>> question is anyone really going to care that much.
>
> I don't think the compiled-in MAC address should be used at all.
>
> For most boards, the compiled-in option is just some random MAC  
> address.  When the board is shipped, the manufacturer creates his  
> own set of environment variables and overrides what's stored on flash.

And where does the mfg store these?

> I actually think that storing a MAC address in a board  
> configuration for or a DTS is a bad idea, because MAC addresses are  
> supposed to be unique for each Ethernet device, and storing a fixed  
> value in a source file breaks that. However, that's a separate  
> issue.  I was just trying to stress that the compiled-in MAC  
> address is of no value.

Ok, so 'compiled-in' wasn't the best choice.  What I meant is 'local- 
mac-address' is the MAC address u-boot decides to use when it boots  
before any user interaction.  (this may be the compiled-in one, or  
one from flash env settings, or whatever other source the board code  
decides).

- k

Re: mac-address vs. local-mac-address

[Timur Tabi]

Benjamin Herrenschmidt wrote:
>> Without a firmware device tree, there's no way to update the device tree and 
>> have that new tree retained over a reboot.
> 
> I don't think it was ever question to update it over reboot...

Well, it is a good idea to use the same MAC address at every boot.  The question 
becomes: when you change the MAC address in Linux, is it possible to retain that 
value over reboot?  If the driver were able to update the *real* OF tree, then 
we could provide that functionality (on OF-enabled systems).

My main point was to define when mac-address should be used, and when 
local-mac-address should be used.

> mac-address is a runtime property that is lost at reboot, at least
> that's my understanding of the OF behaviour. That's where your confusion
> is.

Linux already stores the current MAC address somewhere outside of the OF tree. 
When I reboot the system, does Linux store the current MAC address somewhere?

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

Re: mac-address vs. local-mac-address

[Timur Tabi]

Kumar Gala wrote:

>> For most boards, the compiled-in option is just some random MAC 
>> address.  When the board is shipped, the manufacturer creates his own 
>> set of environment variables and overrides what's stored on flash.
> 
> And where does the mfg store these?

Ideally, on the Ethernet adapters's internal EEPROM.  On non-OF systems, the 
driver is supposed to read the MAC address from the hardware.

> Ok, so 'compiled-in' wasn't the best choice.  What I meant is 
> 'local-mac-address' is the MAC address u-boot decides to use when it 
> boots before any user interaction.  

I agree with that.

> (this may be the compiled-in one, or 
> one from flash env settings, or whatever other source the board code 
> decides).

Well, I think you mean that it should be only the environment variable.  The 
compiled-in version is just a default value for the environment, so that should 
be ignored.  On a few U-Boot Ethernet drivers, the driver queries the hardware 
and fetches the MAC address from it.  The driver then updates the environment 
variable.

So in all case, when U-Boot boots the kernel, it should use the environment 
variable to update local-mac-address, and leave mac-address alone.  I'm trying 
to get a consensus on this proposition.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale