[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <80E9C881-91C8-4F29-B9CE-652F9EE0B018@canonical.com>
Date: Thu, 13 Feb 2020 14:14:06 +0800
From: Kai-Heng Feng <kai.heng.feng@...onical.com>
To: Chun-Hao Lin <hau@...ltek.com>
Cc: Heiner Kallweit <hkallweit1@...il.com>,
Andrew Lunn <andrew@...n.ch>,
Linux Netdev List <netdev@...r.kernel.org>,
Kernel development list <linux-kernel@...r.kernel.org>,
Anthony Wong <anthony.wong@...onical.com>,
Jason Yen <jason.yen@...onical.com>
Subject: Re: SFP+ support for 8168fp/8117
Chun-Hao,
> On Jan 3, 2020, at 12:53, Kai-Heng Feng <kai.heng.feng@...onical.com> wrote:
>
>
>
>> On Jan 3, 2020, at 05:24, Heiner Kallweit <hkallweit1@...il.com> wrote:
>>
>> On 02.01.2020 17:46, Kai-Heng Feng wrote:
>>> Hi Andrew,
>>>
>>>> On Jan 2, 2020, at 23:21, Andrew Lunn <andrew@...n.ch> wrote:
>>>>
>>>> On Thu, Jan 02, 2020 at 02:59:42PM +0800, Kai Heng Feng wrote:
>>>>> Hi Heiner,
>>>>>
>>>>> There's an 8168fp/8117 chip has SFP+ port instead of RJ45, the phy device ID matches "Generic FE-GE Realtek PHY" nevertheless.
>>>>> The problems is that, since it uses SFP+, both BMCR and BMSR read are always zero, so Realtek phylib never knows if the link is up.
>>>>>
>>>>> However, the old method to read through MMIO correctly shows the link is up:
>>>>> static unsigned int rtl8169_xmii_link_ok(struct rtl8169_private *tp)
>>>>> {
>>>>> return RTL_R8(tp, PHYstatus) & LinkStatus;
>>>>> }
>>>>>
>>>>> Few ideas here:
>>>>> - Add a link state callback for phylib like phylink's phylink_fixed_state_cb(). However there's no guarantee that other parts of this chip works.
>>>>> - Add SFP+ support for this chip. However the phy device matches to "Generic FE-GE Realtek PHY" which may complicate things.
>>>>>
>>>>> Any advice will be welcome.
>>>>
>>>> Hi Kai
>>>>
>>>> Is the i2c bus accessible?
>>>
>>> I don't think so. It seems to be a regular Realtek 8168 device with generic PCI ID [10ec:8168].
>>>
>>>> Is there any documentation or example code?
>>>
>>> Unfortunately no.
>>>
>>>>
>>>> In order to correctly support SFP+ cages, we need access to the i2c
>>>> bus to determine what sort of module has been inserted. It would also
>>>> be good to have access to LOS, transmitter disable, etc, from the SFP
>>>> cage.
>>>
>>> Seems like we need Realtek to provide more information to support this chip with SFP+.
>>>
>> Indeed it would be good to have some more details how this chip handles SFP+,
>> therefore I add Hau to the discussion.
>>
>> As I see it the PHY registers are simply dummies on this chip. Or does this chip
>> support both, PHY and SFP+? Hopefully SFP presence can be autodetected, we could
>> skip the complete PHY handling in this case. Interesting would be which parts of
>> the SFP interface are exposed how via (proprietary) registers.
>> Recently the STMMAC driver was converted from phylib to phylink, maybe we have
>> to do the same with r8169 one fine day. But w/o more details this is just
>> speculation, much appreciated would be documentation from Realtek about the
>> SFP+ interface.
>>
>> Kai, which hardware/board are we talking about?
>
> It's a regular Intel PC.
>
> The ethernet is function 1 of the PCI device, function 0 isn't bound to any driver:
> 02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. Device [10ec:816e] (rev 1a)
> 02:00.1 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 22)
Would it be possible to share some info on SFP support?
Kai-Heng
>
> Kai-Heng
>
>>
>>> Kai-Heng
>>>
>>>>
>>>> Andrew
>>>
>> Heiner
>
Powered by blists - more mailing lists