Date:   Fri, 14 Feb 2020 09:07:49 +0000
From:   Hau <hau@...ltek.com>
To:     Kai-Heng Feng <kai.heng.feng@...onical.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?
Hi Kai-Heng,

Could you use r8168 to dump hardware info with following command.
cat /proc/net/r8168/ethx/*

I want to make sure which chip you use and try to add support it in r8168/r8169.

Hau
> 
> Kai-Heng
> 
> >
> > Kai-Heng
> >
> >>
> >>> Kai-Heng
> >>>
> >>>>
> >>>> Andrew
> >>>
> >> Heiner
> >
> 
> 
> ------Please consider the environment before printing this e-mail.

Powered by blists - more mailing lists