RE: SFP+ support for 8168fp/8117

From: Hau
Date: Wed Feb 19 2020 - 09:22:56 EST

Next message: Kai-Heng Feng: "Hard Disk consumes lots of power in s2idle"
Previous message: Anson Huang: "RE: [PATCH V15 1/5] dt-bindings: fsl: scu: add thermal binding"
In reply to: Kai Heng Feng: "Re: SFP+ support for 8168fp/8117"
Next in thread: Kai-Heng Feng: "Re: SFP+ support for 8168fp/8117"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

>
>
>
> > On Feb 14, 2020, at 5:07 PM, Hau <hau@xxxxxxxxxxx> wrote:
> >
> >> Chun-Hao,
> >>
> >>> On Jan 3, 2020, at 12:53, Kai-Heng Feng
> >>> <kai.heng.feng@xxxxxxxxxxxxx>
> >> wrote:
> >>>
> >>>
> >>>
> >>>> On Jan 3, 2020, at 05:24, Heiner Kallweit <hkallweit1@xxxxxxxxx>
> wrote:
> >>>>
> >>>> On 02.01.2020 17:46, Kai-Heng Feng wrote:
> >>>>> Hi Andrew,
> >>>>>
> >>>>>> On Jan 2, 2020, at 23:21, Andrew Lunn <andrew@xxxxxxx> 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.
>
>
> Dump Driver Variable
> Variable Value
> ---------- -----
> MODULENAME r8168
> driver version 8.048.00-NAPI
> chipset 31
> chipset_name RTL8168FP/8111FP
> mtu 1500
> NUM_RX_DESC 0x400
> cur_rx 0x0
> dirty_rx 0x0
> NUM_TX_DESC 0x400
> cur_tx 0x0
> dirty_tx 0x0
> rx_buf_sz 0x5f3
> esd_flag 0x0
> pci_cfg_is_read 0x1
> rtl8168_rx_config 0xcf00
> cp_cmd 0x20e1
> intr_mask 0x115
> timer_intr_mask 0x4000
> wol_enabled 0x1
> wol_opts 0x20
> efuse_ver 0x3
> eeprom_type 0x0
> autoneg 0x1
> duplex 0x1
> speed 1000
> advertising 0x3f
> eeprom_len 0x0
> cur_page 0x0
> bios_setting 0x0
> features 0x2
> org_pci_offset_99 0x0
> org_pci_offset_180 0xf
> issue_offset_99_event 0x0
> org_pci_offset_80 0x42
> org_pci_offset_81 0x1
> use_timer_interrrupt 0x1
> HwIcVerUnknown 0x0
> NotWrRamCodeToMicroP 0x0
> NotWrMcuPatchCode 0x0
> HwHasWrRamCodeToMicroP 0x0
> sw_ram_code_ver 0x3
> hw_ram_code_ver 0x0
> rtk_enable_diag 0x0
> ShortPacketSwChecksum 0x0
> UseSwPaddingShortPkt 0x0
> RequireAdcBiasPatch 0x0
> AdcBiasPatchIoffset 0x0
> RequireAdjustUpsTxLinkPulseTiming 0x0
> SwrCnt1msIni 0x0
> HwSuppNowIsOobVer 0x1
> HwFiberModeVer 0x0
> HwFiberStat 0x0
> HwSwitchMdiToFiber 0x0
> NicCustLedValue 0xca9
> RequiredSecLanDonglePatch 0x0
> HwSuppDashVer 0x3
> DASH 0x1
> dash_printer_enabled 0x0
> HwSuppKCPOffloadVer 0x0
> speed_mode 0x3e8
> duplex_mode 0x1
> autoneg_mode 0x1
> advertising_mode 0x3f
> aspm 0x1
> s5wol 0x1
> s5_keep_curr_mac 0x0
> eee_enable 0x0
> hwoptimize 0x0
> proc_init_num 0x2
> s0_magic_packet 0x0
> HwSuppMagicPktVer 0x2
> HwSuppCheckPhyDisableModeVer 0x3
> HwPkgDet 0x6
> HwSuppGigaForceMode 0x1
> random_mac 0x0
> org_mac_addr 54:b2:03:86:1b:40
> perm_addr 54:b2:03:86:1b:40
> dev_addr 54:b2:03:86:1b:40
>
>
> Dump Ethernet PHY
>
> Offset Value
> ------ -----
>
> ####################page 0##################
>
> 0x00: 1040 7989 001c c800 0de1 0000 0064 2001
> 0x08: 0000 0200 0000 0000 0000 0000 0000 2000
>
> Dump Extended Registers
>
> Offset Value
> ------ -----
>
> 0x00: 00000000 00000000 00000000 00000000
> 0x10: 00000000 00000000 00000000 00000000
> 0x20: 00000000 00000000 00000000 00000000
> 0x30: 00000000 00000000 00000000 00000000
> 0x40: 00000000 00000000 00000000 00000000
> 0x50: 00000000 00000000 00000000 00000000
> 0x60: 00000000 00000000 00000000 00000000
> 0x70: 00000000 00000000 00000000 00000000
> 0x80: 00000000 00000000 00000000 00000000
> 0x90: 00000000 00000000 00000000 00000000
> 0xa0: 00000000 00000000 00000000 00000000
> 0xb0: 00000000 00000000 00000000 00000000
> 0xc0: 00000000 00000000 00080002 0000002f
> 0xd0: 0000005f 00001f92 00000000 001e0021
> 0xe0: 8603b254 0000401b 00100006 00000200
> 0xf0: b2540000 401b8603 00000000 00000000
>
> Dump PCIE PHY
>
> Offset Value
> ------ -----
>
> 0x00: a800 7a58 3cee 2e46 10f0 0004 0000 2600
> 0x08: 6443 3318 0cc3 60b0 11e1 0400 3713 9c20
> 0x10: 000c 4c00 fc01 0c81 de01 0000 0000 0000
> 0x18: 0000 fd01 0312 0ea1 0000 0000 24eb
>
> Dump PCI Registers
>
> Offset Value
> ------ -----
>
> 0x000: 816810ec 00100407 02000022 00800010
> 0x010: 0000d001 00000000 a1108004 00000000
> 0x020: a1100004 00000000 00000000 03441854
> 0x030: 00000000 00000040 00000000 000001ff
> 0x040: ffc35001 00000008 00000000 00000000
> 0x050: 00817005 fee01004 00000000 00004024
> 0x060: 00000000 00000000 00000000 00000000
> 0x070: 0202b010 05908ce0 001b5110 00477c12
> 0x080: 10120142 00000000 00000000 00000000
> 0x090: 00000000 000c181f 00000000 00000006
> 0x0a0: 00010000 00000000 00000000 00000000
> 0x0b0: 00030011 00000004 00000804 00000000
> 0x0c0: 00000000 00000000 00000000 00000000
> 0x0d0: 00000003 00000000 00000000 00000000
> 0x0e0: 00000000 00000000 00000000 00000000
> 0x0f0: 00000000 00000000 00000000 00000000
> 0x110: 00002081
> 0x70c: 27ffff01
>
> Dump MAC Registers
> Offset Value
> ------ -----
>
> 0x00: 54 b2 03 86 1b 40 00 00 00 00 00 00 80 00 00 00
> 0x10: 00 00 6f 79 01 00 00 00 a9 0c 06 00 00 00 00 00
> 0x20: 00 80 99 76 01 00 00 00 00 00 00 00 00 00 00 00
> 0x30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x40: 80 0f a0 57 0e cf 02 00 00 00 00 00 00 00 00 00
> 0x50: 10 00 cf 9c 60 11 03 04 00 00 00 00 00 00 00 00
> 0x60: 00 00 00 00 00 00 00 01 70 f1 01 80 91 00 80 f0
> 0x70: 00 00 00 00 fc f0 00 bf 07 00 00 00 00 00 67 1e
> 0x80: eb 24 1e 80 00 00 00 00 00 00 00 00 00 00 00 00
> 0x90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0xa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0xb0: 00 00 00 00 00 00 00 00 00 20 0f d2 00 00 00 00
> 0xc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0xd0: e1 00 00 32 ac 00 01 00 00 00 f3 05 40 7f b1 00
> 0xe0: e1 20 51 5f 00 c0 99 76 01 00 00 00 3f 00 00 00
> 0xf0: 00 80 40 00 00 00 00 00 ff ff ff ff 00 00 00 00
>
> Dump Tally Counter
> Statistics Value
> ---------- -----
> tx_packets 0
> rx_packets 0
> tx_errors 0
> rx_missed 0
> align_errors 0
> tx_one_collision 0
> tx_multi_collision 0
> rx_unicast 0
> rx_broadcast 0
> rx_multicast 0
> tx_aborted 0
> tx_underun 0
>
>

Hi Kai-Heng,

Attached file is r8168 that I have add SFP+ support for rtl8168fp. If possible, please give it a try.

Hau

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

Attachment: r8168-8.049_20200219_b1.tar.bz2
Description: r8168-8.049_20200219_b1.tar.bz2

Next message: Kai-Heng Feng: "Hard Disk consumes lots of power in s2idle"
Previous message: Anson Huang: "RE: [PATCH V15 1/5] dt-bindings: fsl: scu: add thermal binding"
In reply to: Kai Heng Feng: "Re: SFP+ support for 8168fp/8117"
Next in thread: Kai-Heng Feng: "Re: SFP+ support for 8168fp/8117"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]