D-Link DUB-E100 Revision B1

D-Link DUB-E100 Revision B1

[Bernhard Rosenkraenzer]

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

Looks like D-Link is getting into the funny "change the chipset but leave the 
product name the same" game again.

DUB-E100 cards up to Revision A4 work perfectly, Revision B1 doesn't work at 
all.

The patch I've attached has the beginnings of a fix; unfortunately this 
trivialty doesn't fix it fully -- with the patch, the module loads, the MAC 
address is detected correctly, the LEDs go on, but pings don't get through 
yet.

After loading the module, dmesg says
eth1: register 'asix' at usb-0000:00:10.3-5, ASIX AX88772 USB 2.0 Ethernet, 
00:80:c8:38:53:a7
usbcore: registered new driver asix
PM: Writing back config space on device 0000:00:0c.0 at offset b (was 3ed173b, 
writing 461025)
PM: Writing back config space on device 0000:00:0c.0 at offset 3 (was 0, 
writing 4010)
PM: Writing back config space on device 0000:00:0c.0 at offset 2 (was 2000000, 
writing 2000003)
PM: Writing back config space on device 0000:00:0c.0 at offset 1 (was 2b00000, 
writing 2b00006)
PM: Writing back config space on device 0000:00:0c.0 at offset 0 (was 3ed173b, 
writing 169c14e4)

Chances are it needs some more messing with the .data and/or .flags 
parameters.

[-- Attachment #2: 2.6.17-D-Link-E100-RevB.patch --]
[-- Type: text/x-diff, Size: 690 bytes --]

--- linux-2.6.17/drivers/usb/net/asix.c.ark	2006-06-30 02:21:07.000000000 +0200
+++ linux-2.6.17/drivers/usb/net/asix.c	2006-06-30 02:23:59.000000000 +0200
@@ -868,7 +868,7 @@
 	USB_DEVICE (0x0846, 0x1040),
 	.driver_info =  (unsigned long) &netgear_fa120_info,
 }, {
-	// DLink DUB-E100
+	// DLink DUB-E100, Revision A
 	USB_DEVICE (0x2001, 0x1a00),
 	.driver_info =  (unsigned long) &dlink_dub_e100_info,
 }, {
@@ -924,6 +924,10 @@
 	USB_DEVICE (0x1557, 0x7720),
 	.driver_info = (unsigned long) &ax88772_info,
-},
+}, {
+	// D-Link DUB-E100 Rev. B
+	USB_DEVICE (0x07d1, 0x3c05),
+	.driver_info = (unsigned long) &ax88772_info,
+},
 	{ },		// END
 };
 MODULE_DEVICE_TABLE(usb, products);

Re: D-Link DUB-E100 Revision B1

[David Hollis]

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

On Tue, 2006-07-04 at 03:33 +0200, Bernhard Rosenkraenzer wrote:
> Looks like D-Link is getting into the funny "change the chipset but leave the 
> product name the same" game again.
> 
> DUB-E100 cards up to Revision A4 work perfectly, Revision B1 doesn't work at 
> all.
> 
> The patch I've attached has the beginnings of a fix; unfortunately this 
> trivialty doesn't fix it fully -- with the patch, the module loads, the MAC 
> address is detected correctly, the LEDs go on, but pings don't get through 
> yet.
> 

> Chances are it needs some more messing with the .data and/or .flags 
> parameters.

That's my guess as well.  It probably has a different GPIO configuration
than the other AX88772 devices.  Unfortunately, I haven't been able to
find out what that configuration is.  A USB trace of the Windows driver
initializing the device would be extremely helpful to determine what is
necessary.  I've tried to contact DLink, but it seems to get in depth
technical info like that may take a lot of work.
  
-- 
David Hollis <dhollis@davehollis.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: D-Link DUB-E100 Revision B1

[David Hollis]

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

On Tue, 2006-07-04 at 03:33 +0200, Bernhard Rosenkraenzer wrote:
> Looks like D-Link is getting into the funny "change the chipset but leave the 
> product name the same" game again.
> 
> DUB-E100 cards up to Revision A4 work perfectly, Revision B1 doesn't work at 
> all.
> 
> The patch I've attached has the beginnings of a fix; unfortunately this 
> trivialty doesn't fix it fully -- with the patch, the module loads, the MAC 
> address is detected correctly, the LEDs go on, but pings don't get through 
> yet.
> 

In the ax88772_bind() function, there is a spot where we read the
PHYSID1 and validate that it's 0x003b.  If it's not, we bail out and
don't complete the initialization.  As it turns out, with the B1 rev,
they use an external PHY that has a different identifier so this check
is no longer valid.  Simply removing that check, or getting rid of the
"goto out2;" part, the device appears to operate with no issues.

-- 
David Hollis <dhollis@davehollis.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]