Re: Shuttle DS47 - Realtek RT 8111G

On Sep 15, 2013, at 8:17 PM, Yonghyeon PYUN <pyunyh_at_gmail.com> wrote:

> On Sat, Sep 14, 2013 at 08:47:06PM -0600, Scott Long wrote:
>> Index: sys/dev/re/if_re.c
>> ===================================================================
>> --- sys/dev/re/if_re.c	(revision 255582)
>> +++ sys/dev/re/if_re.c	(working copy)
>> _at__at_ -234,6 +234,10 _at__at_
>> 	{ RL_HWREV_8168E_VL, RL_8169, "8168E/8111E-VL", RL_JUMBO_MTU_6K},
>> 	{ RL_HWREV_8168F, RL_8169, "8168F/8111F", RL_JUMBO_MTU_9K},
>> 	{ RL_HWREV_8411, RL_8169, "8411", RL_JUMBO_MTU_9K},
>> +	{ RL_HWREV_8168_0, RL_8169, "8168G/8111G", RL_JUMBO_MTU_9K},
>> +	{ RL_HWREV_8168_1, RL_8169, "8168G/8111G", RL_JUMBO_MTU_9K},
>> +	{ RL_HWREV_8168_2, RL_8169, "8168G/8111G", RL_JUMBO_MTU_9K},
>> +	{ RL_HWREV_8168_4, RL_8169, "8411", RL_JUMBO_MTU_9K},
>> 	{ 0, 0, NULL, 0 }
>> };
>> 
>> _at__at_ -1457,6 +1461,10 _at__at_
>> 	case RL_HWREV_8168E_VL:
>> 	case RL_HWREV_8168F:
>> 	case RL_HWREV_8411:
>> +	case RL_HWREV_8168G_0:
>> +	case RL_HWREV_8168G_1:
>> +	case RL_HWREV_8168G_2:
>> +	case RL_HWREV_8168G_4:
>> 		sc->rl_flags |= RL_FLAG_PHYWAKE | RL_FLAG_PAR |
>> 		    RL_FLAG_DESCV2 | RL_FLAG_MACSTAT | RL_FLAG_CMDSTOP |
>> 		    RL_FLAG_AUTOPAD | RL_FLAG_JUMBOV2 |
>> Index: sys/pci/if_rlreg.h
>> ===================================================================
>> --- sys/pci/if_rlreg.h	(revision 255582)
>> +++ sys/pci/if_rlreg.h	(working copy)
>> _at__at_ -191,6 +191,10 _at__at_
>> #define	RL_HWREV_8402		0x44000000
>> #define	RL_HWREV_8168F		0x48000000
>> #define	RL_HWREV_8411		0x48800000
>> +#define	RL_HWREV_8168G_0	0x4c000000
>> +#define	RL_HWREV_8168G_1	0x4c100000
> 
> I don't know exact model number for these MACs but it may be 8168G.
> 
>> +#define	RL_HWREV_8168G_2	0x50900000
> 
> This looks like 8168GU.
> 
>> +#define	RL_HWREV_8168G_4	0x5c800000
> 
> This looks like 8411B.
> 
> RL_TXCFG_HWREV is 0x7CC00000 so driver will not see
> RL_HWREV_8168G_1(0x4c100000) and RL_HWREV_8168G_2(0x50900000).
> 
> It seems newer RealTek controllers seem to use ODP to access PHY.
> In addition, these controllers may need to set RX DMA parameter
> (bit 11 of RL_RXCFG). I'm not sure what this bit does though.
> 
> Scott, did you test your patch on real H/W? If it works I'm fine
> with your patch. Just remove RL_HWREV_8168G_1 and RL_HWREV_8168G_2
> as current driver has no way to get these revisions.

I tested the 0x4c00000 on real hardware. an MSI Z87I motherboard.  The rest came from looking at the linux driver.  That driver is structured very differently (and better, IMHO) than the FreeBSD one, so there's a lot that wasn't obvious to me.  I'd be very happy to work more on this with your guidance.

Thanks,
Scott