Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Subject: Re: SFP+ support for 8168fp/8117
From:   Kai-Heng Feng <kai.heng.feng@canonical.com>
In-Reply-To: <c148fefc-fd56-26a8-9f9b-fbefbaf25050@gmail.com>
Date:   Fri, 3 Jan 2020 12:53:38 +0800
Cc:     Andrew Lunn <andrew@lunn.ch>, Chun-Hao Lin <hau@realtek.com>,
        Linux Netdev List <netdev@vger.kernel.org>,
        Kernel development list <linux-kernel@vger.kernel.org>,
        Anthony Wong <anthony.wong@canonical.com>,
        Jason Yen <jason.yen@canonical.com>
Content-Transfer-Encoding: 8BIT
Message-Id: <02F7CBDE-B877-481C-A5AF-2F4CBF830A2C@canonical.com>
References: <2D8F5FFE-3EC3-480B-9D15-23CACE5556DF@canonical.com>
 <20200102152143.GB1397@lunn.ch>
 <DC28A43E-4F1A-40B6-84B0-3E79215527C9@canonical.com>
 <c148fefc-fd56-26a8-9f9b-fbefbaf25050@gmail.com>
To:     Heiner Kallweit <hkallweit1@gmail.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Jan 3, 2020, at 05:24, Heiner Kallweit <hkallweit1@gmail.com> wrote:
> 
> On 02.01.2020 17:46, Kai-Heng Feng wrote:
>> Hi Andrew,
>> 
>>> On Jan 2, 2020, at 23:21, Andrew Lunn <andrew@lunn.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)

Kai-Heng

> 
>> Kai-Heng
>> 
>>> 
>>>  Andrew
>> 
> Heiner