Netdev List
 help / color / mirror / Atom feed
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 */


  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