Great news - thx for the work g. thomas On 29 Oct 2013, at 07:14, Yonghyeon PYUN <pyunyh_at_gmail.com> wrote: > On Sun, Sep 15, 2013 at 09:04:28PM -0600, Scott Long wrote: >> >> 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. >> > > FYI: Fixed in r257304-257306.Received on Tue Oct 29 2013 - 07:56:17 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:43 UTC