[PATCH] Fix byte-swapped ethernet addr for Asante Fast 10/100 PCI Adapter

[PATCH] Fix byte-swapped ethernet addr for Asante Fast 10/100 PCI Adapter

[David D. Kilzer]

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

Re: [PATCH] Fix byte-swapped ethernet addr for Asante Fast 10/100 PCI Adapter

[Michael Schmitz]

>   Original:  00:00:B5:94:71:86  [INCORRECT]
>    Patched:  00:00:94:B5:86:71  [CORRECT]
>
> 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.)

I'd check the first three bytes (after byte swapping :-) - there's plenty
of other OUIs with the leading two bytes zero.

	Michael


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

Re: [PATCH] Fix byte-swapped ethernet addr for Asante Fast 10/100 PCI Adapter

[Benjamin Herrenschmidt]

On Tue, 2003-12-23 at 01:27, Michael Schmitz wrote:
> >   Original:  00:00:B5:94:71:86  [INCORRECT]
> >    Patched:  00:00:94:B5:86:71  [CORRECT]
> >
> > 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.)
>
> I'd check the first three bytes (after byte swapping :-) - there's plenty
> of other OUIs with the leading two bytes zero.

This is a card with an Open Firmware driver or not ? If it has, then
I'd rather use the OF properties (like name property) to detect this
specific card and flip the MAC

Ben.


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

Re: [PATCH] Fix byte-swapped ethernet addr for Asante Fast 10/100 PCI Adapter

[David D. Kilzer]

On Tue, Dec 23, 2003 at 11:05:58AM +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2003-12-23 at 01:27, Michael Schmitz wrote:
> > >   Original:  00:00:B5:94:71:86  [INCORRECT]
> > >    Patched:  00:00:94:B5:86:71  [CORRECT]
> > >
> > > 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.)
> >
> > I'd check the first three bytes (after byte swapping :-) - there's plenty
> > of other OUIs with the leading two bytes zero.
>
> This is a card with an Open Firmware driver or not ? If it has, then
> I'd rather use the OF properties (like name property) to detect this
> specific card and flip the MAC

Please forgive my ignorance, but how do I tell if the card has an OF
driver?  Running "ofpath /dev/eth1" doesn't reveal anything, although
looking at the source for "ofpath" shows me that it doesn't handle
ethernet devices.  I don't see anything under /proc/device-tree/ that
would map to the Asante ethernet card, either.

The card does show up in "lspci" and /proc/pci (obviously).  Would
checking for the PCI vendor/device and subvendor/subdevice be
equivalent to checking for the OF name property?

Thanks!

Dave

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

Re: [PATCH] Fix byte-swapped ethernet addr for Asante Fast 10/100 PCI Adapter

[Benjamin Herrenschmidt]

>
> Please forgive my ignorance, but how do I tell if the card has an OF
> driver?  Running "ofpath /dev/eth1" doesn't reveal anything, although
> looking at the source for "ofpath" shows me that it doesn't handle
> ethernet devices.  I don't see anything under /proc/device-tree/ that
> would map to the Asante ethernet card, either.
>
> The card does show up in "lspci" and /proc/pci (obviously).  Would
> checking for the PCI vendor/device and subvendor/subdevice be
> equivalent to checking for the OF name property?

Not really.

Send me a tarball of /proc/device-tree with the card in along with
lspci -v & lspci -n outputs

Ben.


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

Re: [PATCH] Fix byte-swapped ethernet addr for Asante Fast 10/100 PCI Adapter

[Michael Schmitz]

> > This is a card with an Open Firmware driver or not ? If it has, then
> > I'd rather use the OF properties (like name property) to detect this
> > specific card and flip the MAC
>
> Please forgive my ignorance, but how do I tell if the card has an OF
> driver?  Running "ofpath /dev/eth1" doesn't reveal anything, although
> looking at the source for "ofpath" shows me that it doesn't handle
> ethernet devices.  I don't see anything under /proc/device-tree/ that
> would map to the Asante ethernet card, either.

If there's nothing under /proc/device-tree/, the card doesn't have an OF
driver.

> The card does show up in "lspci" and /proc/pci (obviously).  Would
> checking for the PCI vendor/device and subvendor/subdevice be
> equivalent to checking for the OF name property?

I'm not sure - the card having an OF driver might mean it's a Mac card,
needing byte swapping, whereas a card with no OF driver would be a PC
card, needing no byte swap. Or vice versa. Asante probably never built PC
specific ethernet cards so the PCI vendor/device property could be used
instead of OF data. OF data is just easier to get at :-)

	Michael


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

Re: [PATCH] Fix byte-swapped ethernet addr for Asante Fast 10/100 PCI Adapter

[Geert Uytterhoeven]

On Tue, 23 Dec 2003, Michael Schmitz wrote:
> > > This is a card with an Open Firmware driver or not ? If it has, then
> > > I'd rather use the OF properties (like name property) to detect this
> > > specific card and flip the MAC
> >
> > Please forgive my ignorance, but how do I tell if the card has an OF
> > driver?  Running "ofpath /dev/eth1" doesn't reveal anything, although
> > looking at the source for "ofpath" shows me that it doesn't handle
> > ethernet devices.  I don't see anything under /proc/device-tree/ that
> > would map to the Asante ethernet card, either.
>
> If there's nothing under /proc/device-tree/, the card doesn't have an OF
> driver.
>
> > The card does show up in "lspci" and /proc/pci (obviously).  Would
> > checking for the PCI vendor/device and subvendor/subdevice be
> > equivalent to checking for the OF name property?
>
> I'm not sure - the card having an OF driver might mean it's a Mac card,
> needing byte swapping, whereas a card with no OF driver would be a PC
> card, needing no byte swap. Or vice versa. Asante probably never built PC
> specific ethernet cards so the PCI vendor/device property could be used
> instead of OF data. OF data is just easier to get at :-)

Really? I'd say it's easier to look at the struct pci_dev the Tulip driver
already looks at. Besides, someone may want to try that card in a non-PowerMac,
while still having the correct MAC address.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

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

Re: [PATCH] Fix byte-swapped ethernet addr for Asante Fast 10/100 PCI Adapter

[Michael Schmitz]

> > > The card does show up in "lspci" and /proc/pci (obviously).  Would
> > > checking for the PCI vendor/device and subvendor/subdevice be
> > > equivalent to checking for the OF name property?
> >
> > I'm not sure - the card having an OF driver might mean it's a Mac card,
> > needing byte swapping, whereas a card with no OF driver would be a PC
> > card, needing no byte swap. Or vice versa. Asante probably never built PC
> > specific ethernet cards so the PCI vendor/device property could be used
> > instead of OF data. OF data is just easier to get at :-)
>
> Really? I'd say it's easier to look at the struct pci_dev the Tulip driver

Easier (if you deal with PCI all the time) but what if they also made
non-Mac cards that behave different there? Seeing the OF data just makes
it clearer that we've got the Mac card here.

> already looks at. Besides, someone may want to try that card in a non-PowerMac,
> while still having the correct MAC address.

So we need both detection methods. Since Dave's card didn't seem to have
OF resources, PCI might be the only way here.

	Michael


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

Re: [PATCH] Fix byte-swapped ethernet addr for Asante Fast 10/100 PCI Adapter

[David D. Kilzer]

On Tue, Dec 23, 2003 at 03:01:49PM +0100, Geert Uytterhoeven wrote:
> On Tue, 23 Dec 2003, Michael Schmitz wrote:
> > I'm not sure - the card having an OF driver might mean it's a Mac card,
> > needing byte swapping, whereas a card with no OF driver would be a PC
> > card, needing no byte swap. Or vice versa. Asante probably never built PC
> > specific ethernet cards so the PCI vendor/device property could be used
> > instead of OF data. OF data is just easier to get at :-)
>
> Really? I'd say it's easier to look at the struct pci_dev the Tulip driver
> already looks at. Besides, someone may want to try that card in a
> non-PowerMac, while still having the correct MAC address.

The card is currently in a PowerMac 7200/75 running Debian 3.0 with a
Linux 2.2 kernel.  (It's my firewall. :)

I do have an x86 PC (also running Debian 3.0 but with a 2.4 kernel) that
I could test it on, although this is somewhat inconvenient since I'll be
off the Internet while I'm doing the testing.

BTW, the almighty original box that the ethernet card came in says, "For
PCI-bus PC or Macintosh computers", so it should work in both, in
theory.  I also have original PC and Mac driver disks and the original
documentation in PDF format if that's helpful.

Dave

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

Re: [PATCH] Fix byte-swapped ethernet addr for Asante Fast 10/100 PCI Adapter

[Jeff Garzik]

Geert Uytterhoeven wrote:
> On Tue, 23 Dec 2003, Michael Schmitz wrote:
>>I'm not sure - the card having an OF driver might mean it's a Mac card,
>>needing byte swapping, whereas a card with no OF driver would be a PC
>>card, needing no byte swap. Or vice versa. Asante probably never built PC
>>specific ethernet cards so the PCI vendor/device property could be used
>>instead of OF data. OF data is just easier to get at :-)
>
>
> Really? I'd say it's easier to look at the struct pci_dev the Tulip driver
> already looks at. Besides, someone may want to try that card in a non-PowerMac,
> while still having the correct MAC address.


Agreed.

	Jeff


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

Re: [PATCH] Fix byte-swapped ethernet addr for Asante Fast 10/100 PCI Adapter

[Benjamin Herrenschmidt]

On Sun, 2004-01-25 at 12:48, Jeff Garzik wrote:
> Geert Uytterhoeven wrote:
> > On Tue, 23 Dec 2003, Michael Schmitz wrote:
> >>I'm not sure - the card having an OF driver might mean it's a Mac card,
> >>needing byte swapping, whereas a card with no OF driver would be a PC
> >>card, needing no byte swap. Or vice versa. Asante probably never built PC
> >>specific ethernet cards so the PCI vendor/device property could be used
> >>instead of OF data. OF data is just easier to get at :-)
> >
> >
> > Really? I'd say it's easier to look at the struct pci_dev the Tulip driver
> > already looks at. Besides, someone may want to try that card in a non-PowerMac,
> > while still having the correct MAC address.
>
>
> Agreed.

Provided the card has a unique device ID... but yes, in this case,
it's the best solution.

Ben.


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

Re: [PATCH] Fix byte-swapped ethernet addr for Asante Fast 10/100 PCI Adapter

[David D. Kilzer]

[-- Attachment #1: Type: text/plain, Size: 2558 bytes --]

Attached is my second pass at patches to fix the byte-swapped ethernet
MAC address issue with my tulip-based Asante ethernet card.  Please note
that the patch against 2.4.24 also applies cleanly to 2.6.x (with
offsets).

The approach I took for these patches was to remove the current logic
from the 'if' statement and to put it in its own function (unchanged),
along with new code for identifying the Asante card using PCI
(sub)vendor and (sub)device IDs.  I also did some investigative work
regarding the original code that only checks the first two bytes of the
ethernet MAC address.  This information appears in the comments,
although they are a bit more verbose than the rest of the code.

Finally, it may be possible to replace the new
needs_mac_addr_byte_swapped() function with a check of the PCI vendor
and device IDs, assuming all tulip ethernet cards using the LC82C168
chipset have this same problem (and the same PCI IDs):

	if (pdev->vendor == PCI_VENDOR_ID_LITEON
		&& pdev->device == PCI_DEVICE_ID_LITEON_LNE100TX)
 		for (i = 0; i < 6; i+=2) {
			...
		}

Through Google searches, I've determined that the Kingston boards need
this fix, but there are some Netgear "FA310TX" boards that I'm not sure
about.

I'm looking for more feedback on the patches, unless they're ready to be
included in the kernel.  Some lingering questions I had were:

- Should I check for all 3 ethernet MAC address bytes instead of just
  the first two for the first 'if' statemen, now that I've identified
  what the original code was probably checking for?

- Should I simply replace the needs_mac_addr_byte_swapped() function
  with the PCI vendor/device check shown above?  (I probably shouldn't
  have asked this; would only be useful if someone had such a Netgear
  card on this list and could confirm it.)

- Did I define the subvendor/subdevice constants in pci_ids.h correctly?

- Was I too verbose in my code comments?  If so, where should that
  information be located if not in the code?  Should it be in
  Documentation/DocBook/tulip.tmpl instead?

Thanks!

Dave

On Sun, Jan 25, 2004 at 12:48:38PM +1100, Benjamin Herrenschmidt wrote:
> On Sun, 2004-01-25 at 12:48, Jeff Garzik wrote:
> > Geert Uytterhoeven wrote:
> > > Really? I'd say it's easier to look at the struct pci_dev the
> > > Tulip driver already looks at. Besides, someone may want to try
> > > that card in a non-PowerMac, while still having the correct MAC
> > > address.
> >
> > Agreed.
>
> Provided the card has a unique device ID... but yes, in this case,
> it's the best solution.

[-- Attachment #2: linux-2.2.20-tulip-fix-asante-mac-addr-v2.diff --]
[-- Type: text/plain, Size: 3740 bytes --]

diff -u 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	Sun Feb  1 20:40:36 2004
@@ -26,6 +26,11 @@

 	2002 Dec 21  Neale Banks <neale@lowendale.com.au>
 	Gracefully handle the case where init_etherdev() returns NULL
+
+	2004 Jan 31  David D. Kilzer <ddkilzer@kilzer.net>
+	Moved check for needing to byte-swap MAC address into its own
+	function.  Added code to function to check for the Asante Fast
+	10/100 PCI Adapter Rev B P/N 99-00493-87.
 */

 #define SMP_CHECK
@@ -678,6 +683,73 @@
 }
 #endif  /* not CARDBUS */

+static int needs_mac_addr_byte_swapped(int pci_bus, int pci_devfn,
+	struct device *dev)
+{
+	/*
+	 * Lite-On boards have the mac address byte-swapped.
+	 *
+	 * The code below is checking for the following ethernet MAC
+	 * address combinations (in byte-swapped order):
+	 *
+	 *   00:A0:**
+	 *   00:C0:**
+	 *
+	 * However, only one of these maps directly to a Lite-On
+	 * ethernet vendor code:
+	 *
+	 *   00-A0-CC	LITE-ON COMMUNICATIONS, INC.
+	 *
+	 * The other code is probably for Kingston Technology, who
+	 * distributed their own ethernet cards using Lite-On chips
+	 * (confirmed via Google search of "00:C0 lite-on"):
+	 *
+	 *   00-C0-F0	KINGSTON TECHNOLOGY CORP.
+	 *
+	 * Ethernet vendor codes were found here:
+	 *
+	 *   http://standards.ieee.org/regauth/oui/index.shtml
+	 */
+	if ((dev->dev_addr[0] == 0xA0  ||  dev->dev_addr[0] == 0xC0)
+		&&  dev->dev_addr[1] == 0x00)
+		return 1;
+
+	/*
+	 * Asante Technologies also produced an ethernet card based on
+	 * the Lite-On chipset.
+	 */
+	{
+#if defined(PCI_SUPPORT_VER1)
+		/*
+		 * Fall back to checking for the ethernet vendor code:
+	 	 *   00-00-94	ASANTE TECHNOLOGIES
+		 */
+		if (dev->dev_addr[0] == 0x00 &&  dev->dev_addr[1] == 0x00
+			&&  dev->dev_addr[3] == 0x94)
+			return 1;
+#elif defined(PCI_SUPPORT_VER2)
+		/*
+		 * Check the PCI (sub)vendor and (sub)device instead.
+		 */
+		struct pci_dev *pdev = pci_find_slot(pci_bus, pci_devfn);
+		u16 sub_vendor_id, sub_device_id;
+
+		pcibios_read_config_word(pci_bus, pci_devfn,
+			PCI_SUBSYSTEM_VENDOR_ID, &sub_vendor_id);
+		pcibios_read_config_word(pci_bus, pci_devfn,
+			PCI_SUBSYSTEM_ID,        &sub_device_id);
+
+		if (pdev->vendor == PCI_VENDOR_ID_LITEON
+			&& pdev->device == PCI_DEVICE_ID_LITEON_LNE100TX
+			&& sub_vendor_id == PCI_SUBVENDOR_ID_ASANTE
+			&& sub_device_id == PCI_SUBDEVICE_ID_ASANTE_FAST_10_100_REV_B)
+			return 1;
+#endif
+	}
+
+	return 0;
+}
+
 static struct device *tulip_probe1(int pci_bus, int pci_devfn,
 								   struct device *dev, long ioaddr, int irq,
 								   int chip_idx, int board_idx)
@@ -786,9 +858,9 @@
 			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)
+	/* Boards with the Lite-On LC82C168 chipset have the address
+	   byte-swapped. */
+	if (needs_mac_addr_byte_swapped(pci_bus, pci_devfn, dev))
 		for (i = 0; i < 6; i+=2) {
 			char tmp = dev->dev_addr[i];
 			dev->dev_addr[i] = dev->dev_addr[i+1];
diff -u kernel-source-2.2.20/include/linux/pci.h.orig kernel-source-2.2.20/include/linux/pci.h
--- kernel-source-2.2.20/include/linux/pci.h.orig	Fri Jul  4 18:33:54 2003
+++ kernel-source-2.2.20/include/linux/pci.h	Sun Feb  1 20:16:55 2004
@@ -994,6 +994,9 @@
 #define PCI_VENDOR_ID_LITEON		0x11ad
 #define PCI_DEVICE_ID_LITEON_LNE100TX	0x0002

+#define PCI_SUBVENDOR_ID_ASANTE		0x128a
+#define PCI_SUBDEVICE_ID_ASANTE_FAST_10_100_REV_B	0xf001
+
 #define PCI_VENDOR_ID_NP		0x11bc
 #define PCI_DEVICE_ID_NP_PCI_FDDI	0x0001


[-- Attachment #3: linux-2.4.24-tulip-fix-asante-mac-addr-v2.diff --]
[-- Type: text/plain, Size: 2757 bytes --]

diff -urN -x *.orig linux-2.4.24-orig/drivers/net/tulip/tulip_core.c linux-2.4.24/drivers/net/tulip/tulip_core.c
--- linux-2.4.24-orig/drivers/net/tulip/tulip_core.c	Fri Nov 28 12:26:20 2003
+++ linux-2.4.24/drivers/net/tulip/tulip_core.c	Sun Feb  1 20:43:06 2004
@@ -1322,6 +1322,52 @@
 }
 #endif

+static int __devinit needs_mac_addr_byte_swapped(struct pci_dev *pdev,
+						 struct net_device *dev)
+{
+	/*
+	 * Lite-On boards have the mac address byte-swapped.
+	 *
+	 * The code below is checking for the following ethernet MAC
+	 * address combinations (in byte-swapped order):
+	 *
+	 *   00:A0:**
+	 *   00:C0:**
+	 *
+	 * However, only one of these maps directly to a Lite-On
+	 * ethernet vendor code:
+	 *
+	 *   00-A0-CC	LITE-ON COMMUNICATIONS, INC.
+	 *
+	 * The other code is probably for Kingston Technology, who
+	 * distributed their own ethernet cards using Lite-On chips
+	 * (confirmed via Google search of "00:C0 lite-on"):
+	 *
+	 *   00-C0-F0	KINGSTON TECHNOLOGY CORP.
+	 *
+	 * Ethernet vendor codes were found here:
+	 *
+	 *   http://standards.ieee.org/regauth/oui/index.shtml
+	 */
+	if ((dev->dev_addr[0] == 0xA0  ||  dev->dev_addr[0] == 0xC0)
+		&&  dev->dev_addr[1] == 0x00)
+		return 1;
+
+	/*
+	 * Asante Technologies also produced an ethernet card based on
+	 * the Lite-On chipset.
+	 *
+	 * Check the PCI (sub)vendor and (sub)device instead.
+	 */
+	if (pdev->vendor == PCI_VENDOR_ID_LITEON
+		&& pdev->device == PCI_DEVICE_ID_LITEON_LNE100TX
+		&& pdev->subsystem_vendor == PCI_SUBVENDOR_ID_ASANTE
+		&& pdev->subsystem_device == PCI_SUBDEVICE_ID_ASANTE_FAST_10_100_REV_B)
+		return 1;
+
+	return 0;
+}
+
 static int __devinit tulip_init_one (struct pci_dev *pdev,
 				     const struct pci_device_id *ent)
 {
@@ -1623,9 +1669,9 @@
 			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)
+	/* Boards with the Lite-On LC82C168 chipset have the address
+	   byte-swapped. */
+	if (needs_mac_addr_byte_swapped(pdev, dev))
 		for (i = 0; i < 6; i+=2) {
 			char tmp = dev->dev_addr[i];
 			dev->dev_addr[i] = dev->dev_addr[i+1];
diff -urN -x *.orig linux-2.4.24-orig/include/linux/pci_ids.h linux-2.4.24/include/linux/pci_ids.h
--- linux-2.4.24-orig/include/linux/pci_ids.h	Fri Nov 28 12:26:21 2003
+++ linux-2.4.24/include/linux/pci_ids.h	Sun Feb  1 20:24:29 2004
@@ -1306,6 +1306,9 @@
 #define PCI_VENDOR_ID_LITEON		0x11ad
 #define PCI_DEVICE_ID_LITEON_LNE100TX	0x0002

+#define PCI_SUBVENDOR_ID_ASANTE		0x128a
+#define PCI_SUBDEVICE_ID_ASANTE_FAST_10_100_REV_B	0xf001
+
 #define PCI_VENDOR_ID_V3		0x11b0
 #define PCI_DEVICE_ID_V3_V960		0x0001
 #define PCI_DEVICE_ID_V3_V350		0x0001

Re: [PATCH] Fix byte-swapped ethernet addr for Asante Fast 10/100 PCI Adapter

[David D. Kilzer]

On Sun, Feb 01, 2004 at 11:49:38PM -0600, David D. Kilzer wrote:

> Finally, it may be possible to replace the new
> needs_mac_addr_byte_swapped() function with a check of the PCI vendor
> and device IDs, assuming all tulip ethernet cards using the LC82C168
> chipset have this same problem (and the same PCI IDs):
>
> 	if (pdev->vendor == PCI_VENDOR_ID_LITEON
> 		&& pdev->device == PCI_DEVICE_ID_LITEON_LNE100TX)
>  		for (i = 0; i < 6; i+=2) {
> 			...
> 		}

FWIW, I've ordered both a Kingston KNE100TX and a Netgear FA310TX card
to do some testing on.  I should have results in a week or so, depending
on how fast they're shipped from the eBay sellers.

Netgear 10/100 Network Card - NO SHIPPING!
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&category=58299&item=3075759665

Kingston KNE100TX 10/100 Ethernet Card
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&category=20319&item=3074775351

Dave

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