From: Javen <javen_xu@realsil.com.cn>
To: Maxime Chevallier <maxime.chevallier@bootlin.com>,
"hkallweit1@gmail.com" <hkallweit1@gmail.com>,
"nic_swsd@realtek.com" <nic_swsd@realtek.com>,
"andrew+netdev@lunn.ch" <andrew+netdev@lunn.ch>,
"davem@davemloft.net" <davem@davemloft.net>,
"edumazet@google.com" <edumazet@google.com>,
"kuba@kernel.org" <kuba@kernel.org>,
"pabeni@redhat.com" <pabeni@redhat.com>,
"horms@kernel.org" <horms@kernel.org>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH net-next v1 1/5] net: phy: realtek: add support for dummy phy
Date: Wed, 3 Jun 2026 08:00:43 +0000 [thread overview]
Message-ID: <f614a60942e34bf39b1d49fb273221ab@realsil.com.cn> (raw)
In-Reply-To: <7496c873-fee7-4584-ad70-4315d7b94f8f@bootlin.com>
>On 6/3/26 08:59, javen wrote:
>> From: Javen Xu <javen_xu@realsil.com.cn>
>>
>> Add support for rtl8116af dummy phy driver, match phy id and read link
>> speed from MII_BMCR.
>>
>> Signed-off-by: Javen Xu <javen_xu@realsil.com.cn>
>
>Can you elaborate more on why this is needed ?
>
>The cover says :
>"
>In this mode, the driver
>needs a dummy PHY ID so that phylib can attach to a dummy Realtek PHY
>driver, while selected standard PHY registers are handled through the SerDes
>register.
>"
>
>Why can't you use the SerDes registers for your PHY driver ? The phrase above
>suggests that the "SerDes registers" have the typical C22/45 layout. There are
>PHYs and PCSs out there that aren't accessed through regular MDIO with
>regmap being used to translate the mdio accesses done by phylib into the
>actual register access method used.
>
>Maxime
>
Thanks for your review.
Maybe I shouldn't call it a "dummy" PHY. It is actually a real, dedicated PHY driver for the RTL8116af operating in Fiber/SerDes mode. The reason we cannot use the standard generic PHY driver is that hardware does not correctly populate the standard Gigabit Status Register (MII_STAT1000, Reg 0x0a).
Here is a snippet of our MDIO read trace during link up:
r8169 0000:85:00.1: MDIO read: tp->ocp_base=0xa400, reg=0x0a, value=0x0000
r8169 0000:85:00.1: MDIO read: tp->ocp_base=0xa400, reg=0x05, value=0x41a0
Reg 0x0a returns 0x0000, the phylib generic status parser fails to resolve the 1000Mbps link, causing the driver to incorrectly fall back to a forced 10Mbps, even though the physical link is actually UP at 1000Mbps. Therefore, we need to register a custom PHY driver to provide a specific .read_status callback that parses MII_BMCR instead of relying on MII_STAT1000.
BRs,
Javen
>> ---
>> drivers/net/phy/realtek/realtek_main.c | 54 ++++++++++++++++++++++++++
>> include/net/phy/realtek_phy.h | 1 +
>> 2 files changed, 55 insertions(+)
>>
>> diff --git a/drivers/net/phy/realtek/realtek_main.c
>> b/drivers/net/phy/realtek/realtek_main.c
>> index 27268811f564..9b92828c49d9 100644
>> --- a/drivers/net/phy/realtek/realtek_main.c
>> +++ b/drivers/net/phy/realtek/realtek_main.c
>> @@ -2659,6 +2659,47 @@ static int rtlgen_sfp_get_features(struct
>phy_device *phydev)
>> return 0;
>> }
>>
>> +static int rtl8116af_sfp_get_features(struct phy_device *phydev) {
>> + linkmode_set_bit(ETHTOOL_LINK_MODE_1000baseT_Full_BIT,
>> + phydev->supported);
>> +
>> + phydev->speed = SPEED_1000;
>> + phydev->duplex = DUPLEX_FULL;
>> +
>> + phydev->port = PORT_FIBRE;
>> +
>> + return 0;
>> +}
>> +
>> +static int rtl8116af_sfp_read_status(struct phy_device *phydev) {
>> + int val, err;
>> +
>> + err = genphy_update_link(phydev);
>> + if (err)
>> + return err;
>> +
>> + if (!phydev->link)
>> + return 0;
>> +
>> + val = phy_read(phydev, MII_BMCR);
>> + if (val < 0)
>> + return val;
>> +
>> + if (val & BMCR_SPEED1000)
>> + phydev->speed = SPEED_1000;
>> + else if (val & BMCR_SPEED100)
>> + phydev->speed = SPEED_100;
>> +
>> + if (val & BMCR_FULLDPLX)
>> + phydev->duplex = DUPLEX_FULL;
>> + else
>> + phydev->duplex = DUPLEX_HALF;
>> +
>> + return 0;
>> +}
>> +
>> static int rtlgen_sfp_read_status(struct phy_device *phydev) {
>> int val, err;
>> @@ -2947,6 +2988,19 @@ static struct phy_driver realtek_drvs[] = {
>> .write_page = rtl821x_write_page,
>> .read_mmd = rtl822x_read_mmd,
>> .write_mmd = rtl822x_write_mmd,
>> + }, {
>> + PHY_ID_MATCH_EXACT(PHY_ID_RTL8116AF_DUMMY),
>> + .name = "RTL8116af PHY Mode",
>> + .flags = PHY_IS_INTERNAL,
>> + .get_features = rtl8116af_sfp_get_features,
>> + .config_aneg = rtlgen_sfp_config_aneg,
>> + .read_status = rtl8116af_sfp_read_status,
>> + .suspend = genphy_suspend,
>> + .resume = rtlgen_resume,
>> + .read_page = rtl821x_read_page,
>> + .write_page = rtl821x_write_page,
>> + .read_mmd = rtl822x_read_mmd,
>> + .write_mmd = rtl822x_write_mmd,
>> }, {
>> PHY_ID_MATCH_EXACT(0x001ccad0),
>> .name = "RTL8224 2.5Gbps PHY",
>> diff --git a/include/net/phy/realtek_phy.h
>> b/include/net/phy/realtek_phy.h index d683bc1b0659..cbf91af0ead6
>> 100644
>> --- a/include/net/phy/realtek_phy.h
>> +++ b/include/net/phy/realtek_phy.h
>> @@ -3,5 +3,6 @@
>> #define _REALTEK_PHY_H
>>
>> #define PHY_ID_RTL_DUMMY_SFP 0x001ccbff
>> +#define PHY_ID_RTL8116AF_DUMMY 0x001ccbfe
>>
>> #endif /* _REALTEK_PHY_H */
next prev parent reply other threads:[~2026-06-03 8:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-03 6:59 [PATCH net-next v1 0/5] r8169: fix RTL8116AF low power and link readiness issues javen
2026-06-03 6:59 ` [PATCH net-next v1 1/5] net: phy: realtek: add support for dummy phy javen
2026-06-03 7:38 ` Maxime Chevallier
2026-06-03 8:00 ` Javen [this message]
2026-06-03 8:52 ` Maxime Chevallier
2026-06-03 9:13 ` Javen
2026-06-03 9:48 ` Maxime Chevallier
2026-06-03 10:03 ` Javen
2026-06-03 13:15 ` Andrew Lunn
2026-06-03 6:59 ` [PATCH net-next v1 2/5] r8169: move funcitons forward javen
2026-06-03 6:59 ` [PATCH net-next v1 3/5] r8169: fix RTL8116af link readiness bug javen
2026-06-03 6:59 ` [PATCH net-next v1 4/5] r8169: add ltr support for RTL8116af javen
2026-06-03 6:59 ` [PATCH net-next v1 5/5] r8169: fix RTL8116af can not enter s0idle and c10 javen
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=f614a60942e34bf39b1d49fb273221ab@realsil.com.cn \
--to=javen_xu@realsil.com.cn \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maxime.chevallier@bootlin.com \
--cc=netdev@vger.kernel.org \
--cc=nic_swsd@realtek.com \
--cc=pabeni@redhat.com \
/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