RE: [PATCH v2] ARM: LPC32xx: Ethernet driver

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

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.)

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

	David

Hi,

On 02/28/2012 02:11 PM, David Laight wrote:

quoted

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

thing

quoted

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

one

quoted

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.

Thanks in advance,

Roland

On Tuesday 28 February 2012, Roland Stigge wrote:

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.

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

On 02/28/2012 02:41 PM, Arnd Bergmann wrote:

quoted

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.

Cool, thanks - will do!

Roland

On Tue, 2012-02-28 at 13:41 +0000, Arnd Bergmann wrote:

On Tuesday 28 February 2012, Roland Stigge wrote:

quoted

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.

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

The 3rd option should now be eth_hw_addr_random().

Ben.

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 majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.