Dan Malek writes: > Why don't you want this? Ethernet addresses are supposed to be assigned > to MACs. It's not a good idea to have a MAC appear at different addresses. > This is why it always assigns the same address.
Sure, but there's only provision for a single MAC address in the bd_t struct, and since we're not using the SCC ethernet port, we'd like the FEC to assume this address un-munged. Otherwise the MAC address the ROM monitor tells you about is different to the one the FEC uses. That's excusable as a workaround for the ROM monitor only knowing about a single MAC address when you need to use two ports, but it's unfriendly if you're only using one port. > > ..... It also makes the decision non-board-specific, so other boards > > with dual FEC & SCC ports benefit too: > > That's not good either. I know how EP assigns Ethernet addresses, so > I can do this. Manufacturers are supposed to supply Ethernet addresses > for every MAC they support. The "right" way is to have multiple, known > unique addresses assigned to boards that have multiple MACs. Other > boards may (should) require different assignment methods. True, it just seemed to me to be a better default for other vendors who support both interfaces than the current situation, where both interfaces get the same MAC address. The munged address is still in their OUI block, whereas using the same address on two interfaces is definitely illegal. Perhaps a better board-independent solution to supporting dual interfaces is to have fec.c read the MAC address from "bd->bi_fenetaddr" rather than both fec.c and enet.c reading "bd->bi_enetaddr". Regards, Graham -- Graham Stoney Principal Hardware/Software Engineer Canon Information Systems Research Australia Ph: +61 2 9805 2909 Fax: +61 2 9805 2929 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
