From: ddkilzer@kilzer.net (David D. Kilzer)
To: Jeff Garzik <jgarzik@pobox.com>
Cc: tulip-devel@lists.sourceforge.net, linuxppc-dev@lists.linuxppc.org
Subject: [PATCH] Fix byte-swapped ethernet addr for Asante Fast 10/100 PCI Adapter
Date: Sun, 7 Dec 2003 00:21:53 -0600 [thread overview]
Message-ID: <20031207062153.GB6302@permusion.kilzer.net> (raw)
[-- Attachment #1: Type: text/plain, Size: 2981 bytes --]
Hi,
I'm looking for some feedback on a kernel patch, and how best to fix the
Tulip driver to report a correct mac address with the Asante Fast 10/100
PCI ethernet card that's installed in my PowerMac 7200/75.
The issue is that the byte-order of the mac address is swapped by
default:
Original: 00:00:B5:94:71:86 [INCORRECT]
Patched: 00:00:94:B5:86:71 [CORRECT]
There is code in linux-2.2.20/drivers/net/tulip.c (and in tulip_core.c
in the 2.4.x and 2.6.x kernels) that swaps the byte order of the mac
address by looking at the current, byte-swapped mac address in-place:
> /* Lite-On boards have the address byte-swapped. */
> if ((dev->dev_addr[0] == 0xA0 || dev->dev_addr[0] == 0xC0)
> && dev->dev_addr[1] == 0x00)
> for (i = 0; i < 6; i+=2) {
> char tmp = dev->dev_addr[i];
> dev->dev_addr[i] = dev->dev_addr[i+1];
> dev->dev_addr[i+1] = tmp;
> }
My questions:
Is it sufficient to simply check the first two bytes of the mac address
to determine this? (This is what the attached patch does. I added a
check for the first byte being 0x00 for the Asante card.)
Should the first three bytes of the mac address be used intead? (Note
that I can only identify 00:A0:CC as one of the Lite-On mac addresses
that would be matched by the code segment above. I don't see a 00:C0:**
entry for Lite-On in the IEEE database.)
Should PCI IDs be used in place of mac address values?
Thanks! Below is more information that may be helpful.
Resources:
- IEEE OUI and Company_Id Assignments web site:
http://standards.ieee.org/regauth/oui/index.shtml
- Output to /var/log/syslog when the kernel module is loaded:
Dec 6 23:49:02 stan kernel: tulip.c:v0.91g-ppc 7/16/99 becker@cesdis.gsfc.nasa.gov
Dec 6 23:49:02 stan kernel: eth1: Lite-On 82c168 PNIC rev 32 at 0x400, 00:00:94:B5:86:71, IRQ 24.
Dec 6 23:49:02 stan kernel: eth1: MII transceiver #1 config 3100 status 782d advertising 01e1.
- Output to /var/log/syslog when the interface is brought up:
Dec 6 23:49:05 stan kernel: eth1: Setting full-duplex based on MII#1 link partner capability of 01e1.
- Output from lspci -vvn:
00:0e.0 Class 0200: 11ad:0002 (rev 20)
Subsystem: 128a:f001
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32
Interrupt: pin A routed to IRQ 24
Region 0: I/O ports at 0400
Region 1: Memory at 80800000 (32-bit, non-prefetchable) [disabled]
Expansion ROM at 80840000 [disabled]
- Output from 'cat /proc/pci':
Bus 0, device 14, function 0:
Ethernet controller: LiteOn LNE100TX (rev 32).
Medium devsel. Fast back-to-back capable. IRQ 24. Master Capable. Latency=32.
I/O at 0x400 [0x401].
Non-prefetchable 32 bit memory at 0x80800000 [0x80800000].
- I've added information to the pciids SourceForge project about the
card: http://pciids.sourceforge.net/iii/?i=11ad0002
Dave
[-- Attachment #2: linux-2.2.20-tulip-fix-asante-mac-addr.diff --]
[-- Type: text/plain, Size: 928 bytes --]
diff -u6 kernel-source-2.2.20/drivers/net/tulip.c.orig kernel-source-2.2.20/drivers/net/tulip.c
--- kernel-source-2.2.20/drivers/net/tulip.c.orig Fri Jul 4 17:58:17 2003
+++ kernel-source-2.2.20/drivers/net/tulip.c Sat Dec 6 23:41:30 2003
@@ -783,15 +783,15 @@
}
for (i = 0; i < 6; i ++) {
dev->dev_addr[i] = ee_data[i + sa_offset];
sum += ee_data[i + sa_offset];
}
}
- /* Lite-On boards have the address byte-swapped. */
- if ((dev->dev_addr[0] == 0xA0 || dev->dev_addr[0] == 0xC0)
- && dev->dev_addr[1] == 0x00)
+ /* Lite-On boards have the mac address byte-swapped. */
+ if ((dev->dev_addr[0] == 0x00 || dev->dev_addr[0] == 0xA0 ||
+ dev->dev_addr[0] == 0xC0) && dev->dev_addr[1] == 0x00)
for (i = 0; i < 6; i+=2) {
char tmp = dev->dev_addr[i];
dev->dev_addr[i] = dev->dev_addr[i+1];
dev->dev_addr[i+1] = tmp;
}
/* On the Zynx 315 Etherarray and other multiport boards only the
next reply other threads:[~2003-12-07 6:21 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-07 6:21 David D. Kilzer [this message]
2003-12-22 14:27 ` [PATCH] Fix byte-swapped ethernet addr for Asante Fast 10/100 PCI Adapter Michael Schmitz
2003-12-23 0:05 ` Benjamin Herrenschmidt
2003-12-23 13:15 ` David D. Kilzer
2003-12-23 13:26 ` Benjamin Herrenschmidt
2003-12-23 13:30 ` Michael Schmitz
2003-12-23 14:01 ` Geert Uytterhoeven
2003-12-23 14:32 ` Michael Schmitz
2003-12-23 15:06 ` David D. Kilzer
2004-01-25 1:48 ` Jeff Garzik
2004-01-25 1:48 ` Benjamin Herrenschmidt
2004-02-02 5:49 ` David D. Kilzer
2004-02-05 14:46 ` David D. Kilzer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20031207062153.GB6302@permusion.kilzer.net \
--to=ddkilzer@kilzer.net \
--cc=jgarzik@pobox.com \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=tulip-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).