Tiny fix to fec.c for RPX boards using only fast ethernet

Tiny fix to fec.c for RPX boards using only fast ethernet

[Graham Stoney]

Hi y'all,

There's an elegant engineering solution in fec.c to the problem of RPX boards
with both FEC and SCC ethernet ports. Unfortunately, it isn't desirable if the
SCC port isn't being used, because it still renumbers the FEC MAC address from
the one in the board info structure.

Here's a simple patch that only enables the renumbering if SCC ethernet is
also being used. It also makes the decision non-board-specific, so other boards
with dual FEC & SCC ports benefit too:


*** fec.c.old	Thu Mar 30 10:05:58 2000
--- fec.c	Thu Mar 30 10:06:30 2000
***************
*** 994,1000 ****
  	eap = (unsigned char *)my_enet_addr;
  	iap = bd->bi_enetaddr;

! #ifdef CONFIG_RPXCLASSIC
  	/* The Embedded Planet boards have only one MAC address in
  	 * the EEPROM, but can have two Ethernet ports.  For the
  	 * FEC port, we create another address by setting one of
--- 994,1000 ----
  	eap = (unsigned char *)my_enet_addr;
  	iap = bd->bi_enetaddr;

! #ifdef CONFIG_SCC_ENET
  	/* The Embedded Planet boards have only one MAC address in
  	 * the EEPROM, but can have two Ethernet ports.  For the
  	 * FEC port, we create another address by setting one of

--
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/

Re: Tiny fix to fec.c for RPX boards using only fast ethernet

[Dan Malek]

Graham Stoney wrote:

> .... Unfortunately, it isn't desirable if the
> SCC port isn't being used, because it still renumbers the FEC MAC address from
> the one in the board info structure.

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.

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


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Tiny fix to fec.c for RPX boards using only fast ethernet

[Graham Stoney]

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/

Re: Tiny fix to fec.c for RPX boards using only fast ethernet

[Dan Malek]

Graham Stoney wrote:


> Sure, but there's only provision for a single MAC address in the bd_t
> struct,

The board descriptor is unique to every board configuration.  I have
some boards with three MACs, three unique Ethernet addresses, and the
bd_t has three Ethernet entries.  That's the "right" way.  My latest
change to the RPX Classic is to define two Ethernet addresses, and
these are assigned in the 'embed_config.c' functions.  The FEC just
always chooses the second one (board specific index).

> ....... Otherwise the MAC address the ROM monitor tells
> you about is different to the one the FEC uses.

That is now irrelevant.  The ROM monitor on the RPX boards is going
to be significantly different within weeks.  It will only use the
Ethernet address and the 10 Mbit SCC Ethernet.

> True, it just seemed to me to be a better default for other vendors...

The example will now be in the embedded configuration functions.  Load
your choice of Ethernet addresses there, and the FEC driver is just
built with which to select.  This further flows into the 8260 port
which can support multiple Fast Ethernet controllers.



	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Tiny fix to fec.c for RPX boards using only fast ethernet

[Wolfgang Denk]

In message <20000330024703.3E3C0355E8@elph.research.canon.com.au>
Graham Stoney wrote:
>
> the same MAC address. The munged address is still in their OUI block, whereas
> using the same address on two interfaces is definitely illegal.

Why should this be illegal?

You will run into problem when you try  to  connect  both  interfaces
(having  athe same MAC address) to the same subnet, but why would you
want to do this?

For a common example just look at Sun workstations:  they  _all_  are
using  the  same MAC address for all ethernet interfaces there are in
one box...

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
8 Catfish                                               = 1 Octo-puss

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/