[PATCH net-next 0/2] r8169: add support for RTL8127ATF (10G Fiber SFP)

[PATCH net-next 0/2] r8169: add support for RTL8127ATF (10G Fiber SFP)

[Heiner Kallweit]

RTL8127ATF supports a SFP+ port for fiber modules (10GBASE-SR/LR/ER/ZR and
DAC). The list of supported modes was provided by Realtek. According to the
r8127 vendor driver also 1G modules are supported, but this needs some more
complexity in the driver, and only 10G mode has been tested so far.
Therefore mainline support will be limited to 10G for now.
The SFP port signals are hidden in the chip IP and driven by firmware.
Therefore mainline SFP support can't be used here.
The PHY driver is used by the RTL8127ATF support in r8169.
RTL8127ATF reports the same PHY ID as the TP version. Therefore use a dummy
PHY ID.

Heiner Kallweit (2):
  net: phy: realtek: add PHY driver for RTL8127ATF
  r8169: add support for RTL8127ATF (Fiber SFP)

 MAINTAINERS                               |  1 +
 drivers/net/ethernet/realtek/r8169_main.c | 89 ++++++++++++++++++++++-
 drivers/net/phy/realtek/realtek_main.c    | 54 ++++++++++++++
 include/linux/realtek_phy.h               |  7 ++
 4 files changed, 147 insertions(+), 4 deletions(-)
 create mode 100644 include/linux/realtek_phy.h

-- 
2.52.0

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

[Heiner Kallweit]

RTL8127ATF supports a SFP+ port for fiber modules (10GBASE-SR/LR/ER/ZR and
DAC). The list of supported modes was provided by Realtek. According to the
r8127 vendor driver also 1G modules are supported, but this needs some more
complexity in the driver, and only 10G mode has been tested so far.
Therefore mainline support will be limited to 10G for now.
The SFP port signals are hidden in the chip IP and driven by firmware.
Therefore mainline SFP support can't be used here.
This PHY driver is used by the RTL8127ATF support in r8169.
RTL8127ATF reports the same PHY ID as the TP version. Therefore use a dummy
PHY ID.  This PHY driver is used by the RTL8127ATF support in r8169.

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
 MAINTAINERS                            |  1 +
 drivers/net/phy/realtek/realtek_main.c | 54 ++++++++++++++++++++++++++
 include/linux/realtek_phy.h            |  7 ++++
 3 files changed, 62 insertions(+)
 create mode 100644 include/linux/realtek_phy.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 765ad2daa21..6ede656b009 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9416,6 +9416,7 @@ F:	include/linux/phy_link_topology.h
 F:	include/linux/phylib_stubs.h
 F:	include/linux/platform_data/mdio-bcm-unimac.h
 F:	include/linux/platform_data/mdio-gpio.h
+F:	include/linux/realtek_phy.h
 F:	include/trace/events/mdio.h
 F:	include/uapi/linux/mdio.h
 F:	include/uapi/linux/mii.h
diff --git a/drivers/net/phy/realtek/realtek_main.c b/drivers/net/phy/realtek/realtek_main.c
index eb5b540ada0..b57ef0ce15a 100644
--- a/drivers/net/phy/realtek/realtek_main.c
+++ b/drivers/net/phy/realtek/realtek_main.c
@@ -16,6 +16,7 @@
 #include <linux/module.h>
 #include <linux/delay.h>
 #include <linux/clk.h>
+#include <linux/realtek_phy.h>
 #include <linux/string_choices.h>
 
 #include "../phylib.h"
@@ -2100,6 +2101,45 @@ static irqreturn_t rtl8221b_handle_interrupt(struct phy_device *phydev)
 	return IRQ_HANDLED;
 }
 
+static int rtlgen_sfp_get_features(struct phy_device *phydev)
+{
+	linkmode_set_bit(ETHTOOL_LINK_MODE_10000baseT_Full_BIT,
+			 phydev->supported);
+
+	/* set default mode */
+	phydev->speed = SPEED_10000;
+	phydev->duplex = DUPLEX_FULL;
+
+	phydev->port = PORT_FIBRE;
+
+	return 0;
+}
+
+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);
+	if (val < 0)
+		return val;
+
+	rtlgen_decode_physr(phydev, val);
+
+	return 0;
+}
+
+static int rtlgen_sfp_config_aneg(struct phy_device *phydev)
+{
+	return 0;
+}
+
 static struct phy_driver realtek_drvs[] = {
 	{
 		PHY_ID_MATCH_EXACT(0x00008201),
@@ -2361,6 +2401,20 @@ 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_RTL_DUMMY_SFP),
+		.name		= "Realtek SFP PHY Mode",
+		.flags		= PHY_IS_INTERNAL,
+		.probe		= rtl822x_probe,
+		.get_features	= rtlgen_sfp_get_features,
+		.config_aneg	= rtlgen_sfp_config_aneg,
+		.read_status	= rtlgen_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/linux/realtek_phy.h b/include/linux/realtek_phy.h
new file mode 100644
index 00000000000..d683bc1b065
--- /dev/null
+++ b/include/linux/realtek_phy.h
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _REALTEK_PHY_H
+#define _REALTEK_PHY_H
+
+#define	PHY_ID_RTL_DUMMY_SFP	0x001ccbff
+
+#endif /* _REALTEK_PHY_H */
-- 
2.52.0

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

[Daniel Golle]

On Thu, Jan 08, 2026 at 09:27:06PM +0100, Heiner Kallweit wrote:
> RTL8127ATF supports a SFP+ port for fiber modules (10GBASE-SR/LR/ER/ZR and
> DAC). The list of supported modes was provided by Realtek. According to the
> r8127 vendor driver also 1G modules are supported, but this needs some more
> complexity in the driver, and only 10G mode has been tested so far.
> Therefore mainline support will be limited to 10G for now.
> The SFP port signals are hidden in the chip IP and driven by firmware.
> Therefore mainline SFP support can't be used here.
> This PHY driver is used by the RTL8127ATF support in r8169.
> RTL8127ATF reports the same PHY ID as the TP version. Therefore use a dummy
> PHY ID.  This PHY driver is used by the RTL8127ATF support in r8169.
> 
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> ---
>  MAINTAINERS                            |  1 +
>  drivers/net/phy/realtek/realtek_main.c | 54 ++++++++++++++++++++++++++
>  include/linux/realtek_phy.h            |  7 ++++
>  3 files changed, 62 insertions(+)
>  create mode 100644 include/linux/realtek_phy.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 765ad2daa21..6ede656b009 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9416,6 +9416,7 @@ F:	include/linux/phy_link_topology.h
>  F:	include/linux/phylib_stubs.h
>  F:	include/linux/platform_data/mdio-bcm-unimac.h
>  F:	include/linux/platform_data/mdio-gpio.h
> +F:	include/linux/realtek_phy.h
>  F:	include/trace/events/mdio.h
>  F:	include/uapi/linux/mdio.h
>  F:	include/uapi/linux/mii.h
> diff --git a/drivers/net/phy/realtek/realtek_main.c b/drivers/net/phy/realtek/realtek_main.c
> index eb5b540ada0..b57ef0ce15a 100644
> --- a/drivers/net/phy/realtek/realtek_main.c
> +++ b/drivers/net/phy/realtek/realtek_main.c
> @@ -16,6 +16,7 @@
>  #include <linux/module.h>
>  #include <linux/delay.h>
>  #include <linux/clk.h>
> +#include <linux/realtek_phy.h>
>  #include <linux/string_choices.h>
>  
>  #include "../phylib.h"
> @@ -2100,6 +2101,45 @@ static irqreturn_t rtl8221b_handle_interrupt(struct phy_device *phydev)
>  	return IRQ_HANDLED;
>  }
>  
> +static int rtlgen_sfp_get_features(struct phy_device *phydev)
> +{
> +	linkmode_set_bit(ETHTOOL_LINK_MODE_10000baseT_Full_BIT,
> +			 phydev->supported);
> +
> +	/* set default mode */
> +	phydev->speed = SPEED_10000;
> +	phydev->duplex = DUPLEX_FULL;
> +
> +	phydev->port = PORT_FIBRE;
> +
> +	return 0;
> +}
> +
> +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);

This should be the same as
phy_read(phydev, MII_RESV2); /* on page 0 */
Please try.


> +	if (val < 0)
> +		return val;
> +
> +	rtlgen_decode_physr(phydev, val);
> +
> +	return 0;
> +}
> +
> +static int rtlgen_sfp_config_aneg(struct phy_device *phydev)
> +{
> +	return 0;
> +}
> +
>  static struct phy_driver realtek_drvs[] = {
>  	{
>  		PHY_ID_MATCH_EXACT(0x00008201),
> @@ -2361,6 +2401,20 @@ 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_RTL_DUMMY_SFP),
> +		.name		= "Realtek SFP PHY Mode",
> +		.flags		= PHY_IS_INTERNAL,
> +		.probe		= rtl822x_probe,
> +		.get_features	= rtlgen_sfp_get_features,
> +		.config_aneg	= rtlgen_sfp_config_aneg,
> +		.read_status	= rtlgen_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/linux/realtek_phy.h b/include/linux/realtek_phy.h
> new file mode 100644
> index 00000000000..d683bc1b065
> --- /dev/null
> +++ b/include/linux/realtek_phy.h
> @@ -0,0 +1,7 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _REALTEK_PHY_H
> +#define _REALTEK_PHY_H
> +
> +#define	PHY_ID_RTL_DUMMY_SFP	0x001ccbff
> +
> +#endif /* _REALTEK_PHY_H */
> -- 
> 2.52.0
> 
> 

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

[Fabio Baltieri]

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);
> 
> 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.

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

[Daniel Golle]

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);
> > 
> > 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.

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

[Heiner Kallweit]

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);
>>>
>>> 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.
> 
Speaking for the internal PHY's (at least for all c45-capabale ones):
There's no actual paging in the PHY. r8169 translates each paged access
to a register in MDIO_MMD_VEND2.

> 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.
> 
The access using __mdiobus_c45_read is meant primarily for the internal
PHY's, where the MII bus is provided by r8169, using MAC registers.

> tl;dr: drivers/net/phy/realtek/ has signed up for some serious
> weight-loss program.

Indeed ..

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

[Heiner Kallweit]

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.

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

[Heiner Kallweit]

On 1/8/2026 11:56 PM, Daniel Golle wrote:
> On Thu, Jan 08, 2026 at 09:27:06PM +0100, Heiner Kallweit wrote:
>> RTL8127ATF supports a SFP+ port for fiber modules (10GBASE-SR/LR/ER/ZR and
>> DAC). The list of supported modes was provided by Realtek. According to the
>> r8127 vendor driver also 1G modules are supported, but this needs some more
>> complexity in the driver, and only 10G mode has been tested so far.
>> Therefore mainline support will be limited to 10G for now.
>> The SFP port signals are hidden in the chip IP and driven by firmware.
>> Therefore mainline SFP support can't be used here.
>> This PHY driver is used by the RTL8127ATF support in r8169.
>> RTL8127ATF reports the same PHY ID as the TP version. Therefore use a dummy
>> PHY ID.  This PHY driver is used by the RTL8127ATF support in r8169.
>>
>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>> ---
>>  MAINTAINERS                            |  1 +
>>  drivers/net/phy/realtek/realtek_main.c | 54 ++++++++++++++++++++++++++
>>  include/linux/realtek_phy.h            |  7 ++++
>>  3 files changed, 62 insertions(+)
>>  create mode 100644 include/linux/realtek_phy.h
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 765ad2daa21..6ede656b009 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -9416,6 +9416,7 @@ F:	include/linux/phy_link_topology.h
>>  F:	include/linux/phylib_stubs.h
>>  F:	include/linux/platform_data/mdio-bcm-unimac.h
>>  F:	include/linux/platform_data/mdio-gpio.h
>> +F:	include/linux/realtek_phy.h
>>  F:	include/trace/events/mdio.h
>>  F:	include/uapi/linux/mdio.h
>>  F:	include/uapi/linux/mii.h
>> diff --git a/drivers/net/phy/realtek/realtek_main.c b/drivers/net/phy/realtek/realtek_main.c
>> index eb5b540ada0..b57ef0ce15a 100644
>> --- a/drivers/net/phy/realtek/realtek_main.c
>> +++ b/drivers/net/phy/realtek/realtek_main.c
>> @@ -16,6 +16,7 @@
>>  #include <linux/module.h>
>>  #include <linux/delay.h>
>>  #include <linux/clk.h>
>> +#include <linux/realtek_phy.h>
>>  #include <linux/string_choices.h>
>>  
>>  #include "../phylib.h"
>> @@ -2100,6 +2101,45 @@ static irqreturn_t rtl8221b_handle_interrupt(struct phy_device *phydev)
>>  	return IRQ_HANDLED;
>>  }
>>  
>> +static int rtlgen_sfp_get_features(struct phy_device *phydev)
>> +{
>> +	linkmode_set_bit(ETHTOOL_LINK_MODE_10000baseT_Full_BIT,
>> +			 phydev->supported);
>> +
>> +	/* set default mode */
>> +	phydev->speed = SPEED_10000;
>> +	phydev->duplex = DUPLEX_FULL;
>> +
>> +	phydev->port = PORT_FIBRE;
>> +
>> +	return 0;
>> +}
>> +
>> +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);
> 
> This should be the same as
> phy_read(phydev, MII_RESV2); /* on page 0 */
> Please try.
> 

In case of an integrated PHY a phy_read() effectively is translated
into a rtlgen_read_vend2(). So technically there's no benefit.

I don't have hw with RTL8127ATF, but maybe Fabio can test.

> 
>> +	if (val < 0)
>> +		return val;
>> +
>> +	rtlgen_decode_physr(phydev, val);
>> +
>> +	return 0;
>> +}
>> +
>> +static int rtlgen_sfp_config_aneg(struct phy_device *phydev)
>> +{
>> +	return 0;
>> +}
>> +
>>  static struct phy_driver realtek_drvs[] = {
>>  	{
>>  		PHY_ID_MATCH_EXACT(0x00008201),
>> @@ -2361,6 +2401,20 @@ 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_RTL_DUMMY_SFP),
>> +		.name		= "Realtek SFP PHY Mode",
>> +		.flags		= PHY_IS_INTERNAL,
>> +		.probe		= rtl822x_probe,
>> +		.get_features	= rtlgen_sfp_get_features,
>> +		.config_aneg	= rtlgen_sfp_config_aneg,
>> +		.read_status	= rtlgen_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/linux/realtek_phy.h b/include/linux/realtek_phy.h
>> new file mode 100644
>> index 00000000000..d683bc1b065
>> --- /dev/null
>> +++ b/include/linux/realtek_phy.h
>> @@ -0,0 +1,7 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +#ifndef _REALTEK_PHY_H
>> +#define _REALTEK_PHY_H
>> +
>> +#define	PHY_ID_RTL_DUMMY_SFP	0x001ccbff
>> +
>> +#endif /* _REALTEK_PHY_H */
>> -- 
>> 2.52.0
>>
>>

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

[Fabio Baltieri]

On Fri, Jan 09, 2026 at 08:36:10AM +0100, Heiner Kallweit wrote:
> On 1/8/2026 11:56 PM, Daniel Golle wrote:
> > On Thu, Jan 08, 2026 at 09:27:06PM +0100, Heiner Kallweit wrote:
> >> RTL8127ATF supports a SFP+ port for fiber modules (10GBASE-SR/LR/ER/ZR and
> >> DAC). The list of supported modes was provided by Realtek. According to the
> >> r8127 vendor driver also 1G modules are supported, but this needs some more
> >> complexity in the driver, and only 10G mode has been tested so far.
> >> Therefore mainline support will be limited to 10G for now.
> >> The SFP port signals are hidden in the chip IP and driven by firmware.
> >> Therefore mainline SFP support can't be used here.
> >> This PHY driver is used by the RTL8127ATF support in r8169.
> >> RTL8127ATF reports the same PHY ID as the TP version. Therefore use a dummy
> >> PHY ID.  This PHY driver is used by the RTL8127ATF support in r8169.
> >>
> >> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> >> ---
> >>  MAINTAINERS                            |  1 +
> >>  drivers/net/phy/realtek/realtek_main.c | 54 ++++++++++++++++++++++++++
> >>  include/linux/realtek_phy.h            |  7 ++++
> >>  3 files changed, 62 insertions(+)
> >>  create mode 100644 include/linux/realtek_phy.h
> >>
> >> diff --git a/MAINTAINERS b/MAINTAINERS
> >> index 765ad2daa21..6ede656b009 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -9416,6 +9416,7 @@ F:	include/linux/phy_link_topology.h
> >>  F:	include/linux/phylib_stubs.h
> >>  F:	include/linux/platform_data/mdio-bcm-unimac.h
> >>  F:	include/linux/platform_data/mdio-gpio.h
> >> +F:	include/linux/realtek_phy.h
> >>  F:	include/trace/events/mdio.h
> >>  F:	include/uapi/linux/mdio.h
> >>  F:	include/uapi/linux/mii.h
> >> diff --git a/drivers/net/phy/realtek/realtek_main.c b/drivers/net/phy/realtek/realtek_main.c
> >> index eb5b540ada0..b57ef0ce15a 100644
> >> --- a/drivers/net/phy/realtek/realtek_main.c
> >> +++ b/drivers/net/phy/realtek/realtek_main.c
> >> @@ -16,6 +16,7 @@
> >>  #include <linux/module.h>
> >>  #include <linux/delay.h>
> >>  #include <linux/clk.h>
> >> +#include <linux/realtek_phy.h>
> >>  #include <linux/string_choices.h>
> >>  
> >>  #include "../phylib.h"
> >> @@ -2100,6 +2101,45 @@ static irqreturn_t rtl8221b_handle_interrupt(struct phy_device *phydev)
> >>  	return IRQ_HANDLED;
> >>  }
> >>  
> >> +static int rtlgen_sfp_get_features(struct phy_device *phydev)
> >> +{
> >> +	linkmode_set_bit(ETHTOOL_LINK_MODE_10000baseT_Full_BIT,
> >> +			 phydev->supported);
> >> +
> >> +	/* set default mode */
> >> +	phydev->speed = SPEED_10000;
> >> +	phydev->duplex = DUPLEX_FULL;
> >> +
> >> +	phydev->port = PORT_FIBRE;
> >> +
> >> +	return 0;
> >> +}
> >> +
> >> +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);
> > 
> > This should be the same as
> > phy_read(phydev, MII_RESV2); /* on page 0 */
> > Please try.
> > 
> 
> In case of an integrated PHY a phy_read() effectively is translated
> into a rtlgen_read_vend2(). So technically there's no benefit.
> 
> I don't have hw with RTL8127ATF, but maybe Fabio can test.

Yeah I tried it right away, just replaced the call and then added both
and logged the values, turned the interface down and up, they seem to be
returning the same value. Let me know if you want me to test some
condition in particular.

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

[Jakub Kicinski]

On Thu, 8 Jan 2026 21:27:06 +0100 Heiner Kallweit wrote:
> --- /dev/null
> +++ b/include/linux/realtek_phy.h

How would you feel about putting this in include/net ?
Easy to miss things in linux/, harder to grep, not to
mention that some of our automation (patchwork etc) has
its own delegation rules, not using MAINTAINERS.

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

[Heiner Kallweit]

On 1/9/2026 2:28 AM, Jakub Kicinski wrote:
> On Thu, 8 Jan 2026 21:27:06 +0100 Heiner Kallweit wrote:
>> --- /dev/null
>> +++ b/include/linux/realtek_phy.h
> 
> How would you feel about putting this in include/net ?
> Easy to miss things in linux/, harder to grep, not to
> mention that some of our automation (patchwork etc) has
> its own delegation rules, not using MAINTAINERS.

Fine with me. It was just placed in linux/ because there
are similar PHY headers already.

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

[Heiner Kallweit]

On 1/9/2026 2:28 AM, Jakub Kicinski wrote:
> On Thu, 8 Jan 2026 21:27:06 +0100 Heiner Kallweit wrote:
>> --- /dev/null
>> +++ b/include/linux/realtek_phy.h
> 
> How would you feel about putting this in include/net ?
> Easy to miss things in linux/, harder to grep, not to
> mention that some of our automation (patchwork etc) has
> its own delegation rules, not using MAINTAINERS.

Just sent a v2 with the new header moved to new include/net/phy/.
patchwork is showing a warning rgd a missing new MAINTAINERS entry.
However this new entry is added with the patch:

--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9416,6 +9416,7 @@ F:	include/linux/phy_link_topology.h
 F:	include/linux/phylib_stubs.h
 F:	include/linux/platform_data/mdio-bcm-unimac.h
 F:	include/linux/platform_data/mdio-gpio.h
+F:	include/net/phy/
 F:	include/trace/events/mdio.h
 F:	include/uapi/linux/mdio.h
 F:	include/uapi/linux/mii.h

Bug in the check?


stdout from the check:

New files:
include/net/phy/realtek_phy.h

Modified files:
drivers/net/phy/realtek/realtek_main.c
MAINTAINERS
drivers/net/ethernet/realtek/r8169_main.c

Checking coverage for a new file: include/net/phy/realtek_phy.h
  Section ETHERNET PHY LIBRARY covers ~225 files
  Section NETWORKING [GENERAL] covers ~3556 files
  Section THE REST covers ~590073 files
 MIN 225

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

[Jakub Kicinski]

On Sat, 10 Jan 2026 18:23:06 +0100 Heiner Kallweit wrote:
> On 1/9/2026 2:28 AM, Jakub Kicinski wrote:
> > On Thu, 8 Jan 2026 21:27:06 +0100 Heiner Kallweit wrote:  
> >> --- /dev/null
> >> +++ b/include/linux/realtek_phy.h  
> > 
> > How would you feel about putting this in include/net ?
> > Easy to miss things in linux/, harder to grep, not to
> > mention that some of our automation (patchwork etc) has
> > its own delegation rules, not using MAINTAINERS.  
> 
> Just sent a v2 with the new header moved to new include/net/phy/.
> patchwork is showing a warning rgd a missing new MAINTAINERS entry.
> However this new entry is added with the patch:
> 
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9416,6 +9416,7 @@ F:	include/linux/phy_link_topology.h
>  F:	include/linux/phylib_stubs.h
>  F:	include/linux/platform_data/mdio-bcm-unimac.h
>  F:	include/linux/platform_data/mdio-gpio.h
> +F:	include/net/phy/
>  F:	include/trace/events/mdio.h
>  F:	include/uapi/linux/mdio.h
>  F:	include/uapi/linux/mii.h
> 
> Bug in the check?

My reading of it was basically that it's upset that realtek PHYs don't
have a dedicated maintainer. The check considers the PHY subsystem as
too large for the same people to cover core and all the drivers.
If that's the case then the check is working as expected.
It's just flagging the sub-optimal situation to the maintainers.

I wasn't sure if you'd be willing to create a dedicated MAINTAINERS
entry for Realtek PHYs. The check itself is safe to ignore in this case.

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

[Jakub Kicinski]

On Sat, 10 Jan 2026 10:57:40 -0800 Jakub Kicinski wrote:
> On Sat, 10 Jan 2026 18:23:06 +0100 Heiner Kallweit wrote:
> > On 1/9/2026 2:28 AM, Jakub Kicinski wrote:  
> > > How would you feel about putting this in include/net ?
> > > Easy to miss things in linux/, harder to grep, not to
> > > mention that some of our automation (patchwork etc) has
> > > its own delegation rules, not using MAINTAINERS.    
> > 
> > Just sent a v2 with the new header moved to new include/net/phy/.
> > patchwork is showing a warning rgd a missing new MAINTAINERS entry.
> > However this new entry is added with the patch:
> > 
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -9416,6 +9416,7 @@ F:	include/linux/phy_link_topology.h
> >  F:	include/linux/phylib_stubs.h
> >  F:	include/linux/platform_data/mdio-bcm-unimac.h
> >  F:	include/linux/platform_data/mdio-gpio.h
> > +F:	include/net/phy/
> >  F:	include/trace/events/mdio.h
> >  F:	include/uapi/linux/mdio.h
> >  F:	include/uapi/linux/mii.h
> > 
> > Bug in the check?  
> 
> My reading of it was basically that it's upset that realtek PHYs don't
> have a dedicated maintainer. The check considers the PHY subsystem as
> too large for the same people to cover core and all the drivers.
> If that's the case then the check is working as expected.
> It's just flagging the sub-optimal situation to the maintainers.
> 
> I wasn't sure if you'd be willing to create a dedicated MAINTAINERS
> entry for Realtek PHYs. The check itself is safe to ignore in this case.

PS FWIW the check is our replacement for the utterly useless checkpatch
check that asks for a MAINTAINERS entry every time a new file is added.
I wanted to mute that without feeling guilty for ignoring a potentially
useful suggestion so I coded up a more intelligent check which asks for
MAINTAINERS entry only if the file doesn't fall under any reasonably
sized entry already.

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

[Heiner Kallweit]

On 1/10/2026 8:00 PM, Jakub Kicinski wrote:
> On Sat, 10 Jan 2026 10:57:40 -0800 Jakub Kicinski wrote:
>> On Sat, 10 Jan 2026 18:23:06 +0100 Heiner Kallweit wrote:
>>> On 1/9/2026 2:28 AM, Jakub Kicinski wrote:  
>>>> How would you feel about putting this in include/net ?
>>>> Easy to miss things in linux/, harder to grep, not to
>>>> mention that some of our automation (patchwork etc) has
>>>> its own delegation rules, not using MAINTAINERS.    
>>>
>>> Just sent a v2 with the new header moved to new include/net/phy/.
>>> patchwork is showing a warning rgd a missing new MAINTAINERS entry.
>>> However this new entry is added with the patch:
>>>
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -9416,6 +9416,7 @@ F:	include/linux/phy_link_topology.h
>>>  F:	include/linux/phylib_stubs.h
>>>  F:	include/linux/platform_data/mdio-bcm-unimac.h
>>>  F:	include/linux/platform_data/mdio-gpio.h
>>> +F:	include/net/phy/
>>>  F:	include/trace/events/mdio.h
>>>  F:	include/uapi/linux/mdio.h
>>>  F:	include/uapi/linux/mii.h
>>>
>>> Bug in the check?  
>>
>> My reading of it was basically that it's upset that realtek PHYs don't
>> have a dedicated maintainer. The check considers the PHY subsystem as
>> too large for the same people to cover core and all the drivers.
>> If that's the case then the check is working as expected.
>> It's just flagging the sub-optimal situation to the maintainers.
>>
>> I wasn't sure if you'd be willing to create a dedicated MAINTAINERS
>> entry for Realtek PHYs. The check itself is safe to ignore in this case.
> 
> PS FWIW the check is our replacement for the utterly useless checkpatch
> check that asks for a MAINTAINERS entry every time a new file is added.
> I wanted to mute that without feeling guilty for ignoring a potentially
> useful suggestion so I coded up a more intelligent check which asks for
> MAINTAINERS entry only if the file doesn't fall under any reasonably
> sized entry already.

I see, thanks for the explanation. At the moment realtek_phy.h holds just
a single PHY ID, so it's fine to give it a home with the phylib maintainers.
You're right, it would be good to have dedicated maintainer(s) for the
Realtek PHY drivers. Ideally persons with access to Realtek datasheets.
Maybe based on this discussion somebody volunteers ..

[PATCH net-next 2/2] r8169: add support for RTL8127ATF (Fiber SFP)

[Heiner Kallweit]

RTL8127ATF supports a SFP+ port for fiber modules (10GBASE-SR/LR/ER/ZR and
DAC). The list of supported modes was provided by Realtek. According to the
r8127 vendor driver also 1G modules are supported, but this needs some more
complexity in the driver, and only 10G mode has been tested so far.
Therefore mainline support will be limited to 10G for now.
The SFP port signals are hidden in the chip IP and driven by firmware.
Therefore mainline SFP support can't be used here.

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
 drivers/net/ethernet/realtek/r8169_main.c | 89 ++++++++++++++++++++++-
 1 file changed, 85 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index 755083852ee..cf37b4e6c4a 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -17,6 +17,7 @@
 #include <linux/delay.h>
 #include <linux/ethtool.h>
 #include <linux/phy.h>
+#include <linux/realtek_phy.h>
 #include <linux/if_vlan.h>
 #include <linux/in.h>
 #include <linux/io.h>
@@ -733,6 +734,7 @@ struct rtl8169_private {
 	unsigned supports_gmii:1;
 	unsigned aspm_manageable:1;
 	unsigned dash_enabled:1;
+	bool sfp_mode:1;
 	dma_addr_t counters_phys_addr;
 	struct rtl8169_counters *counters;
 	struct rtl8169_tc_offsets tc_offset;
@@ -1097,6 +1099,10 @@ static int r8168_phy_ocp_read(struct rtl8169_private *tp, u32 reg)
 	if (rtl_ocp_reg_failure(reg))
 		return 0;
 
+	/* Return dummy MII_PHYSID2 in SFP mode to match SFP PHY driver */
+	if (tp->sfp_mode && reg == (OCP_STD_PHY_BASE + 2 * MII_PHYSID2))
+		return PHY_ID_RTL_DUMMY_SFP & 0xffff;
+
 	RTL_W32(tp, GPHY_OCP, reg << 15);
 
 	return rtl_loop_wait_high(tp, &rtl_ocp_gphy_cond, 25, 10) ?
@@ -1154,6 +1160,46 @@ static void r8168_mac_ocp_modify(struct rtl8169_private *tp, u32 reg, u16 mask,
 	raw_spin_unlock_irqrestore(&tp->mac_ocp_lock, flags);
 }
 
+static void r8127_sfp_sds_phy_reset(struct rtl8169_private *tp)
+{
+	RTL_W8(tp, 0x2350, RTL_R8(tp, 0x2350) & ~BIT(0));
+	udelay(1);
+
+	RTL_W16(tp, 0x233a, 0x801f);
+	RTL_W8(tp, 0x2350, RTL_R8(tp, 0x2350) | BIT(0));
+	usleep_range(10, 20);
+}
+
+static void r8127_sfp_init_10g(struct rtl8169_private *tp)
+{
+	int val;
+
+	r8127_sfp_sds_phy_reset(tp);
+
+	RTL_W16(tp, 0x233a, 0x801a);
+	RTL_W16(tp, 0x233e, (RTL_R16(tp, 0x233e) & ~0x3003) | 0x1000);
+
+	r8168_phy_ocp_write(tp, 0xc40a, 0x0000);
+	r8168_phy_ocp_write(tp, 0xc466, 0x0003);
+	r8168_phy_ocp_write(tp, 0xc808, 0x0000);
+	r8168_phy_ocp_write(tp, 0xc80a, 0x0000);
+
+	val = r8168_phy_ocp_read(tp, 0xc804);
+	r8168_phy_ocp_write(tp, 0xc804, (val & ~0x000f) | 0x000c);
+}
+
+static void rtl_sfp_init(struct rtl8169_private *tp)
+{
+	if (tp->mac_version == RTL_GIGA_MAC_VER_80)
+		r8127_sfp_init_10g(tp);
+}
+
+static void rtl_sfp_reset(struct rtl8169_private *tp)
+{
+	if (tp->mac_version == RTL_GIGA_MAC_VER_80)
+		r8127_sfp_sds_phy_reset(tp);
+}
+
 /* Work around a hw issue with RTL8168g PHY, the quirk disables
  * PHY MCU interrupts before PHY power-down.
  */
@@ -2308,6 +2354,36 @@ static void rtl8169_get_eth_ctrl_stats(struct net_device *dev,
 		le32_to_cpu(tp->counters->rx_unknown_opcode);
 }
 
+static int rtl8169_set_link_ksettings(struct net_device *ndev,
+				      const struct ethtool_link_ksettings *cmd)
+{
+	struct rtl8169_private *tp = netdev_priv(ndev);
+	struct phy_device *phydev = tp->phydev;
+	int duplex = cmd->base.duplex;
+	int speed = cmd->base.speed;
+
+	if (!tp->sfp_mode)
+		return phy_ethtool_ksettings_set(phydev, cmd);
+
+	if (cmd->base.autoneg != AUTONEG_DISABLE)
+		return -EINVAL;
+
+	if (!phy_check_valid(speed, duplex, phydev->supported))
+		return -EINVAL;
+
+	mutex_lock(&phydev->lock);
+
+	phydev->autoneg = AUTONEG_DISABLE;
+	phydev->speed = speed;
+	phydev->duplex = duplex;
+
+	rtl_sfp_init(tp);
+
+	mutex_unlock(&phydev->lock);
+
+	return 0;
+}
+
 static const struct ethtool_ops rtl8169_ethtool_ops = {
 	.supported_coalesce_params = ETHTOOL_COALESCE_USECS |
 				     ETHTOOL_COALESCE_MAX_FRAMES,
@@ -2327,7 +2403,7 @@ static const struct ethtool_ops rtl8169_ethtool_ops = {
 	.get_eee		= rtl8169_get_eee,
 	.set_eee		= rtl8169_set_eee,
 	.get_link_ksettings	= phy_ethtool_get_link_ksettings,
-	.set_link_ksettings	= phy_ethtool_set_link_ksettings,
+	.set_link_ksettings	= rtl8169_set_link_ksettings,
 	.get_ringparam		= rtl8169_get_ringparam,
 	.get_pause_stats	= rtl8169_get_pause_stats,
 	.get_pauseparam		= rtl8169_get_pauseparam,
@@ -2435,6 +2511,9 @@ static void rtl8169_init_phy(struct rtl8169_private *tp)
 	    tp->pci_dev->subsystem_device == 0xe000)
 		phy_write_paged(tp->phydev, 0x0001, 0x10, 0xf01b);
 
+	if (tp->sfp_mode)
+		rtl_sfp_init(tp);
+
 	/* We may have called phy_speed_down before */
 	phy_speed_up(tp->phydev);
 
@@ -4800,6 +4879,10 @@ static void rtl8169_down(struct rtl8169_private *tp)
 
 	phy_stop(tp->phydev);
 
+	/* Reset SerDes PHY to bring down fiber link */
+	if (tp->sfp_mode)
+		rtl_sfp_reset(tp);
+
 	rtl8169_update_counters(tp);
 
 	pci_clear_master(tp->pci_dev);
@@ -5459,13 +5542,11 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
 	}
 	tp->aspm_manageable = !rc;
 
-	/* Fiber mode on RTL8127AF isn't supported */
 	if (rtl_is_8125(tp)) {
 		u16 data = r8168_mac_ocp_read(tp, 0xd006);
 
 		if ((data & 0xff) == 0x07)
-			return dev_err_probe(&pdev->dev, -ENODEV,
-					     "Fiber mode not supported\n");
+			tp->sfp_mode = true;
 	}
 
 	tp->dash_type = rtl_get_dash_type(tp);
-- 
2.52.0

Re: [PATCH net-next 2/2] r8169: add support for RTL8127ATF (Fiber SFP)

[Fabio Baltieri]

On Thu, Jan 08, 2026 at 09:28:20PM +0100, Heiner Kallweit wrote:
> RTL8127ATF supports a SFP+ port for fiber modules (10GBASE-SR/LR/ER/ZR and
> DAC). The list of supported modes was provided by Realtek. According to the
> r8127 vendor driver also 1G modules are supported, but this needs some more
> complexity in the driver, and only 10G mode has been tested so far.
> Therefore mainline support will be limited to 10G for now.
> The SFP port signals are hidden in the chip IP and driven by firmware.
> Therefore mainline SFP support can't be used here.
> 
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>

Tested-by: Fabio Baltieri <fabio.baltieri@gmail.com>

Thanks!
Fabio