linux-kernel - SFP+ support for 8168fp/8117

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 2 Jan 2020 14:59:42 +0800
From:   Kai Heng Feng <kai.heng.feng@...onical.com>
To:     Heiner Kallweit <hkallweit1@...il.com>
Cc:     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: SFP+ support for 8168fp/8117

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.

Kai-Heng