fdt: rework fdt_fixup_ethernet() to use env instead of bd_t

Move to using the environment variables 'ethaddr', 'eth1addr', etc.. instead of bd->bi_enetaddr, bi_enet1addr, etc.

This makes the code a bit more flexible to the number of ethernet interfaces. Right now we assume a max of 10 interfaces.

Dear Kumar Gala,

In message <Pine.LNX.
4.64.0808181422320.28491 at blarg.am.freescale.net> you wrote:

Quoted 5 lines

Move to using the environment variables 'ethaddr', 'eth1addr', etc.. instead of bd->bi_enetaddr, bi_enet1addr, etc.

This makes the code a bit more flexible to the number of ethernet interfaces. Right now we assume a max of 10 interfaces.

Hm... where exactly is this artificial limit coming from? Do we really need it?

common/fdt_support.c int fdt_fixup_memory(void *blob, u64 start, u64 size) · line 388

Quoted 6 lines

common/fdt_support.c +6 -0

+		for (i = 0; i < CFG_MAX_NUM_ETH; i++) {
+			sprintf(enet, "ethernet%d", i);
+			sprintf(mac, "eth%daddr",i);
+
+			sprintf(mac, i ? "eth%daddr" : "ethaddr", i);
+			tmp = getenv(mac);

for efficientcy, make this the first action in the loop.

common/fdt_support.c int fdt_fixup_memory(void *blob, u64 start, u64 size) · line 398

Quoted 10 lines

common/fdt_support.c +10 -0

+			path = fdt_getprop(fdt, node, enet, NULL);
+
+			if (!path) {
+				debug("No alias for %s\n", enet);
+				continue;
+			}
+			if (!tmp) {
+				debug("No environment variable for %s\n", mac);
+				continue;
+			}

If we assume, that all existing interfaces must have addresses assigned, we could use a "break" here instead of the "continue". That would be (1) much faster on most boards and (2) would allow us to get rid of the artifical limit of 10.

What do you think?

Quoted 7 lines · Wolfgang Denk

Dear Kumar Gala,

In message <Pine.LNX.

Quoted 3 lines · 4.64.0808181422320.28491 at blarg.am.freescale.net> you wrote:

Move to using the environment variables 'ethaddr', 'eth1addr', etc.. instead of bd->bi_enetaddr, bi_enet1addr, etc.

Quoted 4 lines

Quoted 2 lines

This makes the code a bit more flexible to the number of ethernet interfaces. Right now we assume a max of 10 interfaces.

Hm... where exactly is this artificial limit coming from? Do we really need it?

We need some upper limit to stop checking at.

Quoted 11 lines · Kumar Gala

Quoted 10 lines · Wolfgang Denk

Dear Kumar Gala,

In message <Pine.LNX. [email protected]

Quoted 7 lines

you wrote:
Move to using the environment variables 'ethaddr', 'eth1addr', etc..
instead of bd->bi_enetaddr, bi_enet1addr, etc.

This makes the code a bit more flexible to the number of ethernet interfaces. Right now we assume a max of 10 interfaces.

Quoted 4 lines

Quoted 3 lines

Hm... where exactly is this artificial limit coming from? Do we really
need it?

We need some upper limit to stop checking at.

It might be better (and more efficent) to iterate over the environment, and check each name against the eth*addr pattern.

Quoted 3 lines

It might be better (and more efficent) to iterate over the environment, and check each name against the eth*addr pattern.

Its probably easier/less work to iterate over the aliases looking for "ethernet*" pattern, I can do that if its desired.

Dear Kumar Gala,

In message <594AB220-FA74-4A51-BF54-

Quoted 1 line · C79EBD696A51 at kernel.crashing.org> you wrote:

Quoted 5 lines

Quoted 2 lines

It might be better (and more efficent) to iterate over the environment, and check each name against the eth*addr pattern.

Its probably easier/less work to iterate over the aliases looking for "ethernet*" pattern, I can do that if its desired.

No, I agree with Scott here.

Quoted 6 lines

Quoted 3 lines

This makes the code a bit more flexible to the number of ethernet interfaces. Right now we assume a max of 10 interfaces.

Hm... where exactly is this artificial limit coming from? Do we really need it?

We need some upper limit to stop checking at.

Quoted 6 lines

If we assume, that all existing interfaces must have addresses assigned, we could use a "break" here instead of the "continue". That would be (1) much faster on most boards and (2) would allow us to get rid of the artifical limit of 10.

What do you think?

I dont like making this assumption and do think its too much work to check 10 possible aliases and skip to the next one if it doesn't exist.

Dear Kumar Gala,

Quoted 2 lines · In message <[email protected]> you wrote:

Quoted 2 lines

Quoted 2 lines

This makes the code a bit more flexible to the number of ethernet interfaces. Right now we assume a max of 10 interfaces.

Quoted 3 lines

Quoted 2 lines

Hm... where exactly is this artificial limit coming from? Do we really need it?

We need some upper limit to stop checking at.

The upper limit should be the real (configured) number of network interfaces, not some artificial limit which is either too high or too low.

Quoted 4 lines

Quoted 4 lines

If we assume, that all existing interfaces must have addresses assigned, we could use a "break" here instead of the "continue". That would be (1) much faster on most boards and (2) would allow us to get rid of the artifical limit of 10.

Quoted 3 lines

Quoted 1 line

What do you think?

I dont like making this assumption and do think its too much work to check 10 possible aliases and skip to the next one if it doesn't exist.

I do not want to see any such hard-coded limits if they can be avoided. Which problem do you see to stop here at the first interface that has no MAC address assigned to it?

Best regards,

Wolfgang Denk