ARM: LPC32xx: Ethernet driver

Quoted 1 line

Please use a module_param() instead of a top level kernel parameter.

Actually, remove this entirely, we don't add module parameters to force the ethernet address. That should be done in userland in some fashion.

We've had many discussions about this recently, and this is the consistent policy we want to enforce in all drivers from now on.

Thanks for the note! I actually found out that in many cases, the bootloader already initialized the hardware with the target MAC address so we can use this one.

For the case that it _isn't_ initialized already, is it the right

to use a hard coded default MAC address to be replaced by the final

in userspace? (I found such examples in some current micrel/ and amd/

Quoted 4 lines

Thanks for the note! I actually found out that in many cases, the bootloader already initialized the hardware with the target MAC address so we can use this one.

Quoted 1 line

For the case that it _isn't_ initialized already, is it the right

thing

Quoted 1 line

to use a hard coded default MAC address to be replaced by the final

one

Quoted 1 line

in userspace? (I found such examples in some current micrel/ and amd/

drivers.)

Using a fixed address is a very bad idea ...

Yes, that's why we previously had a cmdline param for it (but removed it upon request from the netdev maintainer).

So if the hardware defaults to 00:00:00:00:00:00, what is the "consistent policy we want to enforce in all drivers"?

A link or hint would be sufficient.

Quoted 4 lines

So if the hardware defaults to 00:00:00:00:00:00, what is the "consistent policy we want to enforce in all drivers"?

A link or hint would be sufficient.

I think the most common strategy for platform drivers these days is

1. use what the hardware provides
2. call of_get_mac_address(dev->of_node, ...)
3. use random_ether_addr

in that order. of_get_mac_address just returns NULL when there is no device tree or no local-mac-address property, so you can put it into the driver right away.

Quoted 6 lines · Roland Stigge

Yes, that's why we previously had a cmdline param for it (but removed it upon request from the netdev maintainer).

So if the hardware defaults to 00:00:00:00:00:00, what is the "consistent policy we want to enforce in all drivers"?

Quoted 1 line

A link or hint would be sufficient.

I think the most common strategy for platform drivers these days is

1. use what the hardware provides
2. call of_get_mac_address(dev->of_node, ...)
3. use random_ether_addr

in that order. of_get_mac_address just returns NULL when there is no device tree or no local-mac-address property, so you can put it into the driver right away.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

For the case that it _isn't_ initialized already, is it the right thing to use a hard coded default MAC address to be replaced by the final one in userspace? (I found such examples in some current micrel/ and amd/ drivers.)