Re: [PATCH net-next 1/2] net: phy: realtek: add PHY driver for RTL8127ATF

[Heiner Kallweit <hkallweit1@gmail.com>]

On 1/9/2026 2:26 AM, Daniel Golle wrote:
> On Thu, Jan 08, 2026 at 11:20:21PM +0000, Fabio Baltieri wrote:
>> On Thu, Jan 08, 2026 at 10:56:14PM +0000, Daniel Golle wrote:
>>>> +static int rtlgen_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 = rtlgen_read_vend2(phydev, RTL_VND2_PHYSR);
>>>
I'll leave it like that for now when sending v2 of this series.
Then you can covert it to phy_read(phydev, RTL_PHYSR) as part of
your series.

>>> This should be the same as
>>> phy_read(phydev, MII_RESV2); /* on page 0 */
>>> Please try.
>>
>> Tried it on my setup, the two calls do indeed seem to return the same
>> value.
> 
> Thank you for confirming that.
> 
> My understanding at this point is that only register 0x10 to 0x17 are
> actually paged (ie. the 3 bits of freedom in the
> RTL822X_VND2_TO_PAGE_REG apply to all pages), and that seems to apply for
> all 1G, 2.5G and 5G (and 10G?) RealTek PHYs.
> 
> Hence we do not need to use paged register access for register 0x0...0xf
> and 0x18..0x1e. And the paged operations we do have there right now can
> all be described as registers on MDIO_MMD_VEND2. And maybe that's what
> we should do then, implementing .read_mmd and .write_mmd similar to
> rtl822xb_read_mmd and rtl822xb_write_mmd for all PHYs, with the only
> difference that for older PHYs all MMDs other than MDIO_MMD_VEND2 have
> to be emulated similar to rtlgen_read_mmd and rtl822x_read_mmd.
> 
> The current way we access MDIO_MMD_VEND2 on older PHYs also also fishy
> as it depends on __mdiobus_c45_read as well as the PHY listening to the
> broadcast address 0: Especially for 1GE PHYs not all MDIO controllers
> are capable of Clause-45 access, and listening on address 0 works (at
> best) if there is only one PHY in the bus doing that, and it can be
> disabled via BIT(13) on PHYCR1. For internal PHYs of PCIe NICs this is
> fine, of course, but for standalone PHYs not really.
> 
> tl;dr: drivers/net/phy/realtek/ has signed up for some serious
> weight-loss program.