All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kai-Heng Feng <kai.heng.feng@canonical.com>
To: Heiner Kallweit <hkallweit1@gmail.com>
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>
Subject: Re: SFP+ support for 8168fp/8117
Date: Fri, 3 Jan 2020 12:53:38 +0800	[thread overview]
Message-ID: <02F7CBDE-B877-481C-A5AF-2F4CBF830A2C@canonical.com> (raw)
In-Reply-To: <c148fefc-fd56-26a8-9f9b-fbefbaf25050@gmail.com>



> 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


  reply	other threads:[~2020-01-03  4:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-02  6:59 SFP+ support for 8168fp/8117 Kai Heng Feng
2020-01-02 15:21 ` Andrew Lunn
2020-01-02 16:46   ` Kai-Heng Feng
2020-01-02 21:24     ` Heiner Kallweit
2020-01-03  4:53       ` Kai-Heng Feng [this message]
2020-02-13  6:14         ` Kai-Heng Feng
2020-02-14  9:07           ` Hau
2020-02-17  6:37             ` Kai Heng Feng
2020-02-19 14:22               ` Hau
2020-02-19 14:48                 ` Kai-Heng Feng
2020-02-27  8:49                   ` Kai-Heng Feng
2020-03-04 15:24                     ` Hau
2020-03-04 15:28                       ` Andrew Lunn
2020-03-05 12:36                         ` Hau
2020-03-06 15:34                         ` Hau
2020-03-06 15:58                           ` Andrew Lunn
2020-03-06 16:33                             ` Heiner Kallweit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=02F7CBDE-B877-481C-A5AF-2F4CBF830A2C@canonical.com \
    --to=kai.heng.feng@canonical.com \
    --cc=andrew@lunn.ch \
    --cc=anthony.wong@canonical.com \
    --cc=hau@realtek.com \
    --cc=hkallweit1@gmail.com \
    --cc=jason.yen@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.