nve: ethernet address reversal code

[Andriy Gapon]

I am wondering what is the purpose of the following pieces of code in
if_nve.c:

/* ... nve_attach ... */
	/* MAC is loaded backwards into h/w reg */
	sc->hwapi->pfnGetNodeAddress(sc->hwapi->pADCX, sc->original_mac_addr);
	for (i = 0; i < 6; i++) {
		eaddr[i] = sc->original_mac_addr[5 - i];
	}
	sc->hwapi->pfnSetNodeAddress(sc->hwapi->pADCX, eaddr);
	bcopy(eaddr, (char *)&sc->sc_macaddr, ETHER_ADDR_LEN);


/* ... nve_detach ... */
	/* Reload unreversed address back into MAC in original state */
	if (sc->original_mac_addr)
		sc->hwapi->pfnSetNodeAddress(sc->hwapi->pADCX,
		    sc->original_mac_addr);

Small note: pointer check in nve_detach is obviously not needed because
sc->original_mac_addr is not a pointer but an array.


I am asking the question for two reasons:

1. [theoretical] I am not sure what pfnSetNodeAddress() is doing, but if
it makes modification in NIC memory that can persist across PC reset or
poweroff, then this code can be dangerous if a machine crashes/hangs/etc.

2. [practical] I recently installed 6.2-RELEASE amd64 on Asus M2N
machine (chipset nForce 430 MCP == MCP61, onboard NIC pci chip id is
03ef). After a small patch to add this ID to nve everything worked very
well (in 1 Gb mode). That is, almost everything: I had a very strange
problems access one particular machine on my LAN. I still don't know
what exactly was the problem, but during its investigation I noticed my
MAC address looked strange compared to other MAC addresses. You, we have
a bunch of machines with identical HW on our LAN, they all run either
Linux or Windows, mine is the only FreeBSD one.
So, my ethernet address was a5:07:9f:f3:18:00, but other guys had
something like 00:18:f3:9f:XX:YY. After some digging around I went into
the sources, changed [5-i] to [i] and everything started to work perfectly.
Then I looked at some other machine that uses nve: FreeBSD 6.1 i386,
Abit NF7 motherboard (nForce2 chipset). MAC address there is
00:50:8d:4d:aa:83, which looks pretty normal.

So I am wondering if this is a 64-bit thing or something specific to a
particular chipset. Unfortunately, I can not test i386 version of
FreeBSD (patched to recognize my chipset) on this hardware now.

P.S. just in case, here's a verbose dmesg after both of my patches and
kldunload/kldload:
Mar 14 19:05:32 rein kernel: pci0:7:0: reprobing on driver added
Mar 14 19:05:32 rein kernel: nve0: <NVIDIA nForce MCP14 Networking
Adapter> port 0xe480-0xe487 mem 0xddefd000-0xddefdfff irq 20 at device 7.0
 on pci0
Mar 14 19:05:32 rein kernel: nve0: nvenetlib.o version 1.0-13
Mar 14 19:05:32 rein kernel: nve0: Ethernet address 00:18:f3:9f:07:a5
Mar 14 19:05:32 rein kernel: miibus0: <MII bus> on nve0
Mar 14 19:05:32 rein kernel: ukphy0: <Generic IEEE 802.3u media
interface> on miibus0
Mar 14 19:05:32 rein kernel: ukphy0: OUI 0x001374, model 0x0001, rev. 6
Mar 14 19:05:32 rein kernel: ukphy0:  10baseT, 10baseT-FDX, 100baseTX,
100baseTX-FDX, 1000baseT-FDX, auto
Mar 14 19:05:32 rein kernel: nve0: bpf attached
Mar 14 19:05:32 rein kernel: nve0: Ethernet address: 00:18:f3:9f:07:a5
Mar 14 19:05:32 rein kernel: nve0: [MPSAFE]
Mar 14 19:05:32 rein kernel: pci1: driver added
Mar 14 19:05:32 rein kernel: pci2: driver added
Mar 14 19:05:32 rein kernel: found->    vendor=0x10de, dev=0x016a,
revid=0xa1
Mar 14 19:05:32 rein kernel: bus=2, slot=0, func=0
Mar 14 19:05:32 rein kernel: class=03-00-00, hdrtype=0x00, mfdev=0
Mar 14 19:05:32 rein kernel: cmdreg=0x0007, statreg=0x0010, cachelnsz=16
(dwords)
Mar 14 19:05:32 rein kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns),
maxlat=0x00 (0 ns)
Mar 14 19:05:32 rein kernel: intpin=a, irq=16
Mar 14 19:05:32 rein kernel: powerspec 2  supports D0 D3  current D0
Mar 14 19:05:32 rein kernel: MSI supports 1 message, 64 bit


-- 
Andriy Gapon