i386/142974: [patch][net][if_re] Teach the if_re driver to properly recognize hardware revisions with non-zero MAC rev. bits

[Pyun YongHyeon]

On Sat, Jan 23, 2010 at 03:42:55PM +0200, Shteryana Shopova wrote:
> Hi,
> 
> On Fri, Jan 22, 2010 at 9:59 PM,  <yongari at freebsd.org> wrote:
> > Synopsis: [patch][net][if_re] Teach the if_re driver to properly recognize hardware revisions with non-zero MAC rev. bits
> >
> > State-Changed-From-To: open->feedback
> > State-Changed-By: yongari
> > State-Changed-When: Fri Jan 22 19:57:19 UTC 2010
> > State-Changed-Why:
> > It looks like you have second generation RTL8168C PCIe controller.
> 
> If I understand correctly the RTL8168C PCIe is a Gigabit Ethernet
> controller and mine's definately a Fast Ethernet
> 
> > I guess hwrev variable would have value 0x34c00000 and I don't see
> > reason why it can't match an entry in re_hwrevs table which already
> > has that entry.
> 
> Well, actually there's no 0x34C00000 in the Known revision codes,
> there's a 0x3C400000, but that's different, that's why the chip
> doesn't match any of the known HW ids. I really think the driver's
> biting three bits more than it can chew here
> 

Sorry, have no idea why I read it as 0x3C400000 instead of
0x34C00000.

> > Would you show me the output of "CSR_READ_4(sc, RL_TXCFG)"?
> 
> 0x37c00000
> 

OMG! This is completely new controller.

> This is dmesg with the SVN driver -
> 
> Jan 23 11:55:31  kernel: re0: <RealTek 8101E/8102E/8102EL PCIe
> 10/100baseTX> port 0xec00-0xecff mem
> 0xfebff000-0xfebfffff,0xfdff0000-0xfdffffff irq 18 at device 0.0 on
> pci3
> Jan 23 11:55:31  kernel: re0: Using 1 MSI messages
> Jan 23 11:55:31  kernel: re0: Chip rev. 0x34800000
> Jan 23 11:55:31  kernel: re0: MAC rev. 0x00400000
> Jan 23 11:55:31  kernel: re0: Unknown H/W revision: 0x34c00000
> Jan 23 11:55:31  kernel: device_attach: re0 attach returned 6
> 
> dmesg after patch -
> 
> Jan 23 12:58:04  kernel: re0: <RealTek 8101E/8102E/8102EL PCIe
> 10/100baseTX> port 0xec00-0xecff mem
> 0xfebff000-0xfebfffff,0xfdff0000-0xfdffffff irq 18 at device 0.0 on
> pci3
> Jan 23 12:58:04  kernel: re0: Using 1 MSI messages
> Jan 23 12:58:04  kernel: re0: HWREV - 0x37c00000
> Jan 23 12:58:04  kernel: re0: Chip rev. 0x34800000
> Jan 23 12:58:04  kernel: re0: MAC rev. 0x00400000
> Jan 23 12:58:04  kernel: miibus0: <MII bus> on re0
> Jan 23 12:58:04  kernel: re0: Ethernet address: 90:fb:a6:29:80:cd
> Jan 23 12:58:04  kernel: re0: [FILTER]
> Jan 23 13:00:31  kernel: re0: link state changed to UP
> Jan 23 13:00:40  dhclient: New Hostname (re0):
> Jan 23 13:00:40  dhclient: New IP Address (re0): 192.168.1.103
> Jan 23 13:00:40  dhclient: New Subnet Mask (re0): 255.255.255.0
> Jan 23 13:00:40  dhclient: New Broadcast Address (re0): 255.255.255.255
> Jan 23 13:00:40  dhclient: New Routers (re0): 192.168.1.1
> 
> Just as a sidenote if it would help to understand the problem easier,
> while debugging the issue I used as a reference the DragonflyBSD
> driver - and more specifically this commit -
> http://www.mail-archive.com/commits@crater.dragonflybsd.org/msg09347.html
> 

Can't comment on these changes. sephe seems to have other ideas on
handling RealTek's broken silicon revision naming.

Anyway, would you try attached patch? I'm not entirely sure whether
my patch is correct or not but I just added minimal support for
the new controller(RTL8103E series). RTL8103E seems to have
additional registers related with power control/WOL so I'm not sure
the patch is enough to make suspend/resume/WOL work too.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: re.RTL8103E.diff
Type: text/x-diff
Size: 1419 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20100123/92e93a0f/re.RTL8103E.bin