From: Hau <hau@realtek.com>
To: Kai Heng Feng <kai.heng.feng@canonical.com>
Cc: Heiner Kallweit <hkallweit1@gmail.com>,
Andrew Lunn <andrew@lunn.ch>,
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: Wed, 19 Feb 2020 14:22:22 +0000 [thread overview]
Message-ID: <cae39cfbb5174c8884328887cdfb5a89@realtek.com> (raw)
In-Reply-To: <12EA7285-06D7-44D3-B033-4F52A06123CC@canonical.com>
[-- Attachment #1: Type: text/plain, Size: 9306 bytes --]
>
>
>
> > On Feb 14, 2020, at 5:07 PM, Hau <hau@realtek.com> wrote:
> >
> >> Chun-Hao,
> >>
> >>> On Jan 3, 2020, at 12:53, Kai-Heng Feng
> >>> <kai.heng.feng@canonical.com>
> >> wrote:
> >>>
> >>>
> >>>
> >>>> 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)
> >>
> >> 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 #2: r8168-8.049_20200219_b1.tar.bz2 --]
[-- Type: application/octet-stream, Size: 109474 bytes --]
next prev parent reply other threads:[~2020-02-19 14:23 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
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 [this message]
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=cae39cfbb5174c8884328887cdfb5a89@realtek.com \
--to=hau@realtek.com \
--cc=andrew@lunn.ch \
--cc=anthony.wong@canonical.com \
--cc=hkallweit1@gmail.com \
--cc=jason.yen@canonical.com \
--cc=kai.heng.feng@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).