Great news - thx for the work
g.
thomas
On 29 Oct 2013, at 07:14, Yonghyeon PYUN <pyu...@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 <pyu...@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)
>>>> @@ -234,6 +234,10 @@
>>>> { 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 }
>>>> };
>>>>
>>>> @@ -1457,6 +1461,10 @@
>>>> 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)
>>>> @@ -191,6 +191,10 @@
>>>> #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.
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
