All of lore.kernel.org
 help / color / mirror / Atom feed
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 --]

  reply	other threads:[~2020-02-19 14:22 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 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.