[PATCH net-next v2 0/4] r8152: Add support for the RTL8159 10Gbit USB Ethernet chip

[PATCH net-next v2 0/4] r8152: Add support for the RTL8159 10Gbit USB Ethernet chip

[Birger Koblitz]

Add support for the RTL8159, which is a 10GBit USB-Ethernet adapter
chip in the RTL815x family of chips.

The RTL8159 re-uses the frame descriptor format and SRAM2 access introduced
with the RTL8157 as well as most of the setup and PM logic of the RTL8157.

The module was tested with a Lekuo DR59R11 USB-C 10GbE Ethernet Adapter:
[ 2502.906947] usb 2-1: new SuperSpeed USB device number 3 using xhci_hcd
[ 2502.927859] usb 2-1: New USB device found, idVendor=0bda, idProduct=815a, bcdDevice=30.00
[ 2502.927867] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=7
[ 2502.927871] usb 2-1: Product: USB 10/100/1G/2.5G/5G/10G LAN
[ 2502.927873] usb 2-1: Manufacturer: Realtek
[ 2502.927875] usb 2-1: SerialNumber: 000388C9B3B5XXXX
[ 2503.063745] r8152-cfgselector 2-1: reset SuperSpeed USB device number 3 using xhci_hcd
[ 2503.123876] r8152 2-1:1.0: Requesting firmware: rtl_nic/rtl8159-1.fw
[ 2503.126267] r8152 2-1:1.0: PHY firmware installed 0 to be loaded: 20
[ 2503.156265] r8152 2-1:1.0: load rtl8159-1 v1 2026/01/01 successfully
[ 2503.270729] r8152 2-1:1.0 eth0: v1.12.13
[ 2503.289349] r8152 2-1:1.0 enx88c9b3b5xxxx: renamed from eth0
[ 2507.777055] r8152 2-1:1.0 enx88c9b3b5xxxx: carrier on

The RTL8159 adapter was tested against an AQC107 PCIe-card supporting
10GBit/s and an RTL8157 5Gbit USB-Ethernet adapter supporting 5GBit/s for
performance, link speed and EEE negotiation. Using USB3.2 Gen 2 (20GBit) with
the RTL8159 USB adapter and running iperf3 against the AQC107 PCIe
card resulted in 8.96 Gbits/sec transfer speed.

The code is based on the out-of-tree r8152 driver published by Realtek under
the GPL.

The RTL8159 requires firmware for the PHY in order to achieve a 10GBit link
speed. Without firmware, only 5GBit were achieved. The firmware can be
extracted from the out-of-tree r8152 driver-code where it is stored in the
ram17 u8-array. Code is added to use the existing firmware upload mechanism
of the driver for the RTL8157/9 PHY firmware code. The firmware will be
submitted separately to linux-firmware.

Signed-off-by: Birger Koblitz <mail@birger-koblitz.de>
---
Changes in v2:
- Correct formatting of comments
- Order case statement values correctly
- Add error message when backup-restore fails
- Correct commit message of support for firmware upload
- Link to v1: https://lore.kernel.org/r/20260428-rtl8159_net_next-v1-0-52d03927b46f@birger-koblitz.de

---
Birger Koblitz (4):
      r8152: Add support for 10Gbit Link Speeds and EEE
      r8152: Add support for the RTL8159 chip
      r8152: Add irq mitigation for RTL8157/9
      r8152: Add firmware upload capability for RTL8157/RTL8159

 drivers/net/usb/r8152.c | 336 ++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 324 insertions(+), 12 deletions(-)
---
base-commit: 35c2c39832e569449b9192fa1afbbc4c66227af7
change-id: 20260427-rtl8159_net_next-4f778a614fa7

Best regards,
-- 
Birger Koblitz <mail@birger-koblitz.de>

[PATCH net-next v2 1/4] r8152: Add support for 10Gbit Link Speeds and EEE

[Birger Koblitz]

The RTL8159 supports 10GBit Link speeds. Add support for this speed
in the setup and setting/getting through ethtool. Also add 10GBit EEE.
Add functionality for setup and ethtool get/set methods.

Signed-off-by: Birger Koblitz <mail@birger-koblitz.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
 drivers/net/usb/r8152.c | 58 ++++++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 55 insertions(+), 3 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 7337bf1b7d6ad03572edbc492706c07a8f58760f..01e65d845f8732f23427305423e4e270dae775dc 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -621,6 +621,7 @@ enum spd_duplex {
 	FORCE_1000M_FULL,
 	NWAY_2500M_FULL,
 	NWAY_5000M_FULL,
+	NWAY_10000M_FULL,
 };
 
 /* OCP_ALDPS_CONFIG */
@@ -742,6 +743,7 @@ enum spd_duplex {
 #define BP4_SUPER_ONLY		0x1578	/* RTL_VER_04 only */
 
 enum rtl_register_content {
+	_10000bps	= BIT(14),
 	_5000bps	= BIT(12),
 	_2500bps	= BIT(10),
 	_1250bps	= BIT(9),
@@ -757,6 +759,8 @@ enum rtl_register_content {
 
 #define is_speed_2500(_speed)	(((_speed) & (_2500bps | LINK_STATUS)) == (_2500bps | LINK_STATUS))
 #define is_speed_5000(_speed)	(((_speed) & (_5000bps | LINK_STATUS)) == (_5000bps | LINK_STATUS))
+#define is_speed_10000(_speed)	(((_speed) & (_10000bps | LINK_STATUS)) \
+				 == (_10000bps | LINK_STATUS))
 #define is_flow_control(_speed)	(((_speed) & (_tx_flow | _rx_flow)) == (_tx_flow | _rx_flow))
 
 #define RTL8152_MAX_TX		4
@@ -1008,6 +1012,7 @@ struct r8152 {
 
 	u32 support_2500full:1;
 	u32 support_5000full:1;
+	u32 support_10000full:1;
 	u32 lenovo_macpassthru:1;
 	u32 dell_tb_rx_agg_bug:1;
 	u16 ocp_base;
@@ -1260,6 +1265,7 @@ enum tx_csum_stat {
 #define RTL_ADVERTISED_1000_FULL		BIT(5)
 #define RTL_ADVERTISED_2500_FULL		BIT(6)
 #define RTL_ADVERTISED_5000_FULL		BIT(7)
+#define RTL_ADVERTISED_10000_FULL		BIT(8)
 
 /* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
  * The RTL chips use a 64 element hash table based on the Ethernet CRC.
@@ -5773,6 +5779,11 @@ static void r8156_eee_en(struct r8152 *tp, bool enable)
 	else
 		config &= ~MDIO_EEE_5GT;
 
+	if (enable && (tp->eee_adv2 & MDIO_EEE_10GT))
+		config |= MDIO_EEE_10GT;
+	else
+		config &= ~MDIO_EEE_10GT;
+
 	ocp_reg_write(tp, OCP_EEE_ADV2, config);
 }
 
@@ -6513,6 +6524,9 @@ static int rtl8152_set_speed(struct r8152 *tp, u8 autoneg, u32 speed, u8 duplex,
 
 			if (tp->support_5000full)
 				support |= RTL_ADVERTISED_5000_FULL;
+
+			if (tp->support_10000full)
+				support |= RTL_ADVERTISED_10000_FULL;
 		}
 
 		advertising &= support;
@@ -6559,9 +6573,10 @@ static int rtl8152_set_speed(struct r8152 *tp, u8 autoneg, u32 speed, u8 duplex,
 				r8152_mdio_write(tp, MII_CTRL1000, new1);
 		}
 
-		if (tp->support_2500full || tp->support_5000full) {
+		if (tp->support_2500full || tp->support_5000full || tp->support_10000full) {
 			orig = ocp_reg_read(tp, OCP_10GBT_CTRL);
-			new1 = orig & ~(MDIO_AN_10GBT_CTRL_ADV2_5G | MDIO_AN_10GBT_CTRL_ADV5G);
+			new1 = orig & ~(MDIO_AN_10GBT_CTRL_ADV2_5G | MDIO_AN_10GBT_CTRL_ADV5G
+					| MDIO_AN_10GBT_CTRL_ADV10G);
 
 			if (advertising & RTL_ADVERTISED_2500_FULL) {
 				new1 |= MDIO_AN_10GBT_CTRL_ADV2_5G;
@@ -6573,6 +6588,11 @@ static int rtl8152_set_speed(struct r8152 *tp, u8 autoneg, u32 speed, u8 duplex,
 				tp->ups_info.speed_duplex = NWAY_5000M_FULL;
 			}
 
+			if (advertising & RTL_ADVERTISED_10000_FULL) {
+				new1 |= MDIO_AN_10GBT_CTRL_ADV10G;
+				tp->ups_info.speed_duplex = NWAY_10000M_FULL;
+			}
+
 			if (orig != new1)
 				ocp_reg_write(tp, OCP_10GBT_CTRL, new1);
 		}
@@ -8723,7 +8743,10 @@ int rtl8152_get_link_ksettings(struct net_device *netdev,
 	linkmode_mod_bit(ETHTOOL_LINK_MODE_5000baseT_Full_BIT,
 			 cmd->link_modes.supported, tp->support_5000full);
 
-	if (tp->support_2500full || tp->support_5000full) {
+	linkmode_mod_bit(ETHTOOL_LINK_MODE_10000baseT_Full_BIT,
+			 cmd->link_modes.supported, tp->support_10000full);
+
+	if (tp->support_2500full || tp->support_5000full || tp->support_10000full) {
 		u16 ocp_10gbt_ctrl = ocp_reg_read(tp, OCP_10GBT_CTRL);
 		u16 ocp_10gbt_stat = ocp_reg_read(tp, OCP_10GBT_STAT);
 
@@ -8752,6 +8775,19 @@ int rtl8152_get_link_ksettings(struct net_device *netdev,
 			if (is_speed_5000(rtl8152_get_speed(tp)))
 				cmd->base.speed = SPEED_5000;
 		}
+
+		if (tp->support_10000full) {
+			linkmode_mod_bit(ETHTOOL_LINK_MODE_10000baseT_Full_BIT,
+					 cmd->link_modes.advertising,
+					 ocp_10gbt_ctrl & MDIO_AN_10GBT_CTRL_ADV10G);
+
+			linkmode_mod_bit(ETHTOOL_LINK_MODE_10000baseT_Full_BIT,
+					 cmd->link_modes.lp_advertising,
+					 ocp_10gbt_stat & MDIO_AN_10GBT_STAT_LP10G);
+
+			if (is_speed_10000(rtl8152_get_speed(tp)))
+				cmd->base.speed = SPEED_10000;
+		}
 	}
 
 	mutex_unlock(&tp->control);
@@ -8805,6 +8841,10 @@ static int rtl8152_set_link_ksettings(struct net_device *dev,
 		     cmd->link_modes.advertising))
 		advertising |= RTL_ADVERTISED_5000_FULL;
 
+	if (test_bit(ETHTOOL_LINK_MODE_10000baseT_Full_BIT,
+		     cmd->link_modes.advertising))
+		advertising |= RTL_ADVERTISED_10000_FULL;
+
 	mutex_lock(&tp->control);
 
 	ret = rtl8152_set_speed(tp, cmd->base.autoneg, cmd->base.speed,
@@ -8968,6 +9008,13 @@ static int r8153_get_eee(struct r8152 *tp, struct ethtool_keee *eee)
 			linkmode_set_bit(ETHTOOL_LINK_MODE_5000baseT_Full_BIT, common);
 	}
 
+	if (tp->support_10000full) {
+		linkmode_set_bit(ETHTOOL_LINK_MODE_10000baseT_Full_BIT, eee->supported);
+
+		if (speed & _10000bps)
+			linkmode_set_bit(ETHTOOL_LINK_MODE_10000baseT_Full_BIT, common);
+	}
+
 	eee->eee_enabled = tp->eee_en;
 
 	if (speed & _1000bps)
@@ -9982,6 +10029,11 @@ static int rtl8152_probe_once(struct usb_interface *intf,
 			tp->speed = SPEED_5000;
 			tp->advertising |= RTL_ADVERTISED_5000_FULL;
 		}
+		if (tp->support_10000full &&
+		    tp->udev->speed >= USB_SPEED_SUPER) {
+			tp->speed = SPEED_10000;
+			tp->advertising |= RTL_ADVERTISED_10000_FULL;
+		}
 		tp->advertising |= RTL_ADVERTISED_1000_FULL;
 	}
 	tp->duplex = DUPLEX_FULL;

-- 
2.47.3

Re: [PATCH net-next v2 1/4] r8152: Add support for 10Gbit Link Speeds and EEE

[Jakub Kicinski]

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
r8152: Add support for 10Gbit Link Speeds and EEE

This change adds support for 10 Gbit link speeds on RTL8159 via the
ethtool link_ksettings interface and adds 10 Gbit EEE advertisement
handling alongside the existing 2.5G/5G paths.

> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index 7337bf1b7d6a..01e65d845f87 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c

[ ... ]

> @@ -5773,6 +5779,11 @@ static void r8156_eee_en(struct r8152 *tp, bool enable)
>  	else
>  		config &= ~MDIO_EEE_5GT;
>  
> +	if (enable && (tp->eee_adv2 & MDIO_EEE_10GT))
> +		config |= MDIO_EEE_10GT;
> +	else
> +		config &= ~MDIO_EEE_10GT;
> +
>  	ocp_reg_write(tp, OCP_EEE_ADV2, config);
>  }

Is MDIO_EEE_10GT actually a bit of the EEE advertisement 2 register
(7.62, cap2 / OCP_EEE_ADV2)?

MDIO_EEE_10GT is defined by IEEE 802.3 as a bit of the EEE advertisement
register 7.60 (cap1 / OCP_EEE_ADV), not of register 7.62. The existing
10G EEE advertisement already flows through tp->eee_adv (populated by
linkmode_to_mii_eee_cap1_t() in r8152_set_eee()) and is written to
OCP_EEE_ADV by rtl_eee_enable().

tp->eee_adv2 is populated only by linkmode_to_mii_eee_cap2_t() in
r8152_set_eee(), which covers 2500baseT and 5000baseT and cannot set
MDIO_EEE_10GT, plus the chip-init assignments in rtl_ops_init() which
also do not set this bit.

With that in mind, is the enable && (tp->eee_adv2 & MDIO_EEE_10GT)
condition ever true?  The else branch will then unconditionally clear
bit 3 of OCP_EEE_ADV2 on every call, which is a cap1 bit being written
into the cap2 register.

[ ... ]

> @@ -8968,6 +9008,13 @@ static int r8153_get_eee(struct r8152 *tp, struct ethtool_keee *eee)
>  			linkmode_set_bit(ETHTOOL_LINK_MODE_5000baseT_Full_BIT, common);
>  	}
>  
> +	if (tp->support_10000full) {
> +		linkmode_set_bit(ETHTOOL_LINK_MODE_10000baseT_Full_BIT, eee->supported);
> +
> +		if (speed & _10000bps)
> +			linkmode_set_bit(ETHTOOL_LINK_MODE_10000baseT_Full_BIT, common);
> +	}
> +
>  	eee->eee_enabled = tp->eee_en;

Should this hunk also extend the earlier gating inside r8153_get_eee()?

A few lines above, the cap2 register reads are still gated on:

	if (tp->support_2500full || tp->support_5000full) {
		val = ocp_reg_read(tp, OCP_EEE_ADV2);
		mii_eee_cap2_mod_linkmode_adv_t(eee->advertised, val);

		val = ocp_reg_read(tp, OCP_EEE_LPABLE2);
		mii_eee_cap2_mod_linkmode_adv_t(eee->lp_advertised, val);
	}

The equivalent disjunction in rtl8152_set_speed() and
rtl8152_get_link_ksettings() was updated to include support_10000full,
but r8153_get_eee() (and r8152_set_eee() at the analogous spot) still
only checks support_2500full || support_5000full.

A hypothetical chip that sets only support_10000full would bypass the
OCP_EEE_ADV2 / OCP_EEE_LPABLE2 reads and never reflect 10G EEE into
eee->advertised.  Should the condition be made consistent with the
other sites?

> @@ -9982,6 +10029,11 @@ static int rtl8152_probe_once(struct usb_interface *intf,
>  			tp->speed = SPEED_5000;
>  			tp->advertising |= RTL_ADVERTISED_5000_FULL;
>  		}
> +		if (tp->support_10000full &&
> +		    tp->udev->speed >= USB_SPEED_SUPER) {
> +			tp->speed = SPEED_10000;
> +			tp->advertising |= RTL_ADVERTISED_10000_FULL;
> +		}
>  		tp->advertising |= RTL_ADVERTISED_1000_FULL;
>  	}
>  	tp->duplex = DUPLEX_FULL;

Is USB_SPEED_SUPER the correct gate for defaulting to a 10 Gbit link?

USB_SPEED_SUPER is USB 3.0 SuperSpeed at 5 Gbit/s signaling, which
cannot carry a 10 Gbit Ethernet link.  The minimum bus rate that can
sustain 10GBASE-T is USB_SPEED_SUPER_PLUS (USB 3.1 Gen 2, 10 Gbit/s).

With this check, a 10G-capable RTL8159 plugged into a USB 3.0 host
will still default to tp->speed = SPEED_10000 and advertise
RTL_ADVERTISED_10000_FULL, so the Ethernet link may negotiate at 10G
while the USB bus is bottlenecked well below that, leading to
misleading ethtool speed reporting and back-pressure on the bus.

The same >= USB_SPEED_SUPER gate is reused from the 2.5G and 5G
defaults, which fit inside the USB 3.0 envelope; should the 10G
default instead use >= USB_SPEED_SUPER_PLUS?
-- 
pw-bot: cr

Re: [PATCH net-next v2 1/4] r8152: Add support for 10Gbit Link Speeds and EEE

[Birger Koblitz]

Thanks a lot for reviewing this patch, Jakub!
On 01/05/2026 3:15 am, Jakub Kicinski wrote:

>> +	if (enable && (tp->eee_adv2 & MDIO_EEE_10GT))
>> +		config |= MDIO_EEE_10GT;
>> +	else
>> +		config &= ~MDIO_EEE_10GT;
>> +
>>   	ocp_reg_write(tp, OCP_EEE_ADV2, config);
>>   }
> 
> Is MDIO_EEE_10GT actually a bit of the EEE advertisement 2 register
> (7.62, cap2 / OCP_EEE_ADV2)?
> 
No, and it should have been clear to me. The entire bit of code is 
actually unneccessary, as the MDIO_EEE_10GT-BIT is part of OCP_EEE_ADV 
and is set in tp->eee_adv, so that rtl_eee_enable() correctly already 
sets it:
static void rtl_eee_enable(struct r8152 *tp, bool enable)
{
	case RTL_VER_17:
		if (enable) {
			r8156_eee_en(tp, true);
			ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
		}
	...
}
Will be fixed in v3.

> 
> [ ... ]
> 
>> @@ -8968,6 +9008,13 @@ static int r8153_get_eee(struct r8152 *tp, struct ethtool_keee *eee)
>>   			linkmode_set_bit(ETHTOOL_LINK_MODE_5000baseT_Full_BIT, common);
>>   	}
>>   
>> +	if (tp->support_10000full) {
>> +		linkmode_set_bit(ETHTOOL_LINK_MODE_10000baseT_Full_BIT, eee->supported);
>> +
>> +		if (speed & _10000bps)
>> +			linkmode_set_bit(ETHTOOL_LINK_MODE_10000baseT_Full_BIT, common);
>> +	}
>> +
>>   	eee->eee_enabled = tp->eee_en;
> 
> Should this hunk also extend the earlier gating inside r8153_get_eee()?
> 
> A few lines above, the cap2 register reads are still gated on:
> 
> 	if (tp->support_2500full || tp->support_5000full) {
> 		val = ocp_reg_read(tp, OCP_EEE_ADV2);
> 		mii_eee_cap2_mod_linkmode_adv_t(eee->advertised, val);
> 
> 		val = ocp_reg_read(tp, OCP_EEE_LPABLE2);
> 		mii_eee_cap2_mod_linkmode_adv_t(eee->lp_advertised, val);
> 	}
> 
> The equivalent disjunction in rtl8152_set_speed() and
> rtl8152_get_link_ksettings() was updated to include support_10000full,
> but r8153_get_eee() (and r8152_set_eee() at the analogous spot) still
> only checks support_2500full || support_5000full.
> 
> A hypothetical chip that sets only support_10000full would bypass the
> OCP_EEE_ADV2 / OCP_EEE_LPABLE2 reads and never reflect 10G EEE into
> eee->advertised.  Should the condition be made consistent with the
> other sites?
The AI here actually contradicts itself with the previous issue. The 
10GBit modes are part of OCP_EEE_ADV (MMD 7.0x003C) and OCP_EEE_LPABLE 
(MMD 7.0x003D). A hypothetical chip that sets only support_10000full 
would still reflect the correct LP-ability 10GBit setting.

> 
>> @@ -9982,6 +10029,11 @@ static int rtl8152_probe_once(struct usb_interface *intf,
>>   			tp->speed = SPEED_5000;
>>   			tp->advertising |= RTL_ADVERTISED_5000_FULL;
>>   		}
>> +		if (tp->support_10000full &&
>> +		    tp->udev->speed >= USB_SPEED_SUPER) {
>> +			tp->speed = SPEED_10000;
>> +			tp->advertising |= RTL_ADVERTISED_10000_FULL;
>> +		}
>>   		tp->advertising |= RTL_ADVERTISED_1000_FULL;
>>   	}
>>   	tp->duplex = DUPLEX_FULL;
> 
> Is USB_SPEED_SUPER the correct gate for defaulting to a 10 Gbit link?
I believe this is the correct gate. In order to get the full speed out 
of the 10GBit Ethernet connection, a 20GBit USB link would be needed, 
anyway, with 10GBit USB-C, i.e. USB_SPEED_SUPER_PLUS, I see only about 
7.6GBit throughput. The difference of 10GBit wire-speed to 5GBit Speed 
for USB 3.0 is not that bad, and the overhead does not seem to make a 
problem.

But I think this is not the point: an important aspect of the 10GBit 
USB-Ethernet adapters is that they are used for testing 10GBit 
connections with network equipment. The RTL8159 is even put in 
connection with a media converter and an SFP+ cage in the same housing 
and advertised for testing 10GBit fiber lines. It should be possible to 
test and use 10GBit connectivity even on a 5GBit USB port.

Birger

[PATCH net-next v2 2/4] r8152: Add support for the RTL8159 chip

[Birger Koblitz]

The RTL8157 re-uses the packet descriptor format introduced with the
RTL8157 and other hardware features of the RTL8157 (RTL_VER_16) such
as the SRAM access. The support therefore consists in expanding the
existing RTL8157 code for initialization and USB power management
to also be used for the RTL8159 (RTL_VER_17).

Most of the addiitonal code is added in r8157_hw_phy_cfg() to configure
the RTL8159 PHY.

Add support for the USB device ID of Realtek RTL8157-based adapters. Detect
the RTL8159 as RTL_VER_17 and set it up.

Signed-off-by: Birger Koblitz <mail@birger-koblitz.de>
---
 drivers/net/usb/r8152.c | 257 ++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 249 insertions(+), 8 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 01e65d845f8732f23427305423e4e270dae775dc..2a07dde289e2240b221664ae5c5bceec35b5a1ef 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1247,6 +1247,7 @@ enum rtl_version {
 	RTL_VER_14,
 	RTL_VER_15,
 	RTL_VER_16,
+	RTL_VER_17,
 
 	RTL_VER_MAX
 };
@@ -3432,6 +3433,7 @@ static void rtl8152_nic_reset(struct r8152 *tp)
 		break;
 
 	case RTL_VER_16:
+	case RTL_VER_17:
 		ocp_byte_clr_bits(tp, MCU_TYPE_PLA, PLA_CR, CR_RE | CR_TE);
 		break;
 
@@ -3471,6 +3473,9 @@ static void rtl_eee_plus_en(struct r8152 *tp, bool enable)
 
 static void rtl_set_eee_plus(struct r8152 *tp)
 {
+	if (tp->version == RTL_VER_17)
+		return rtl_eee_plus_en(tp, false);
+
 	if (rtl8152_get_speed(tp) & _10bps)
 		rtl_eee_plus_en(tp, true);
 	else
@@ -3656,6 +3661,7 @@ static void r8153_set_rx_early_timeout(struct r8152 *tp)
 	case RTL_VER_13:
 	case RTL_VER_15:
 	case RTL_VER_16:
+	case RTL_VER_17:
 		ocp_write_word(tp, MCU_TYPE_USB, USB_RX_EARLY_TIMEOUT,
 			       640 / 8);
 		ocp_write_word(tp, MCU_TYPE_USB, USB_RX_EXTRA_AGGR_TMR,
@@ -3700,6 +3706,7 @@ static void r8153_set_rx_early_size(struct r8152 *tp)
 			       ocp_data / 8);
 		break;
 	case RTL_VER_16:
+	case RTL_VER_17:
 		ocp_write_word(tp, MCU_TYPE_USB, USB_RX_EARLY_SIZE,
 			       ocp_data / 16);
 		break;
@@ -4548,6 +4555,7 @@ static void rtl_clear_bp(struct r8152 *tp, u16 type)
 		break;
 	case RTL_VER_14:
 	case RTL_VER_16:
+	case RTL_VER_17:
 	default:
 		ocp_write_word(tp, type, USB_BP2_EN, 0);
 		bp_num = 16;
@@ -5823,6 +5831,7 @@ static void rtl_eee_enable(struct r8152 *tp, bool enable)
 	case RTL_VER_13:
 	case RTL_VER_15:
 	case RTL_VER_16:
+	case RTL_VER_17:
 		if (enable) {
 			r8156_eee_en(tp, true);
 			ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
@@ -6894,7 +6903,7 @@ static void rtl8156_down(struct r8152 *tp)
 			  PLA_MCU_SPDWN_EN);
 
 	r8153b_u1u2en(tp, false);
-	if (tp->version != RTL_VER_16) {
+	if (tp->version < RTL_VER_16) {
 		r8153_u2p3en(tp, false);
 		r8153b_power_cut_en(tp, false);
 	}
@@ -8016,7 +8025,7 @@ static void r8157_hw_phy_cfg(struct r8152 *tp)
 	/* Advanced Power Saving parameter */
 	ocp_reg_set_bits(tp, 0xa430, BIT(0) | BIT(1));
 
-	/* aldpsce force mode */
+	/* Disable ALDPS force mode */
 	ocp_reg_clr_bits(tp, 0xa44a, BIT(2));
 
 	switch (tp->version) {
@@ -8140,6 +8149,190 @@ static void r8157_hw_phy_cfg(struct r8152 *tp)
 		sram2_write_w0w1(tp, 0x807c, 0xff00, 0x5000);
 		sram2_write_w0w1(tp, 0x809d, 0xff00, 0x5000);
 		break;
+
+	case RTL_VER_17:
+		/* Disable bypass turn off clk in ALDPS */
+		 ocp_byte_clr_bits(tp, MCU_TYPE_PLA, 0xd3c8, BIT(0));
+
+		/* Power level tuning
+		 * test mode power level
+		 */
+		sram_write_w0w1(tp, 0x8415, 0xff00, 0x9300);
+		/* normal link power level 10G, 5G, 2.5G */
+		sram_write_w0w1(tp, 0x81a3, 0xff00, 0x0f00);
+		sram_write_w0w1(tp, 0x81ae, 0xff00, 0x0f00);
+		sram_write_w0w1(tp, 0x81b9, 0xff00, 0xb900);
+		/* nomal link TX filter */
+		sram2_write_w0w1(tp, 0x83b0, 0x0e00, 0);
+		sram2_write_w0w1(tp, 0x83c5, 0x0e00, 0);
+		sram2_write_w0w1(tp, 0x83da, 0x0e00, 0);
+		sram2_write_w0w1(tp, 0x83ef, 0x0e00, 0);
+
+		/* AFE power saving for 2.5G & 5G */
+		sram_write(tp, 0x8173, 0x8620);
+		sram_write(tp, 0x8175, 0x8671);
+
+		sram_write_w0w1(tp, 0x817c, 0, BIT(13));
+		sram_write_w0w1(tp, 0x8187, 0, BIT(13));
+		sram_write_w0w1(tp, 0x8192, 0, BIT(13));
+		sram_write_w0w1(tp, 0x819d, 0, BIT(13));
+		sram_write_w0w1(tp, 0x81a8, BIT(13), 0);
+		sram_write_w0w1(tp, 0x81b3, BIT(13), 0);
+		sram_write_w0w1(tp, 0x81be, 0, BIT(13));
+
+		sram_write_w0w1(tp, 0x817d, 0xff00, 0xa600);
+		sram_write_w0w1(tp, 0x8188, 0xff00, 0xa600);
+		sram_write_w0w1(tp, 0x8193, 0xff00, 0xa600);
+		sram_write_w0w1(tp, 0x819e, 0xff00, 0xa600);
+		sram_write_w0w1(tp, 0x81a9, 0xff00, 0x1400);
+		sram_write_w0w1(tp, 0x81b4, 0xff00, 0x1400);
+		sram_write_w0w1(tp, 0x81bf, 0xff00, 0xa600);
+
+		/* RFI parameter
+		 * disable preset FBE
+		 */
+		ocp_reg_clr_bits(tp, 0xaeaa, BIT(5) | BIT(3));
+		/* modify PGA for 5G&10G */
+		sram2_write(tp, 0x84f0, 0x201c);
+		sram2_write(tp, 0x84f2, 0x3117);
+		/* RFI parameter */
+		ocp_reg_write(tp, 0xaec6, 0x0000);
+		ocp_reg_write(tp, 0xae20, 0xffff);
+		ocp_reg_write(tp, 0xaece, 0xffff);
+		ocp_reg_write(tp, 0xaed2, 0xffff);
+		ocp_reg_write(tp, 0xaec8, 0x0000);
+		ocp_reg_clr_bits(tp, 0xaed0, BIT(0));
+		ocp_reg_write(tp, 0xadb8, 0x0150);
+		sram2_write_w0w1(tp, 0x8197, 0xff00, 0x5000);
+		sram2_write_w0w1(tp, 0x8231, 0xff00, 0x5000);
+		sram2_write_w0w1(tp, 0x82cb, 0xff00, 0x5000);
+		sram2_write_w0w1(tp, 0x82cd, 0xff00, 0x5700);
+		sram2_write_w0w1(tp, 0x8233, 0xff00, 0x5700);
+		sram2_write_w0w1(tp, 0x8199, 0xff00, 0x5700);
+
+		sram2_write(tp, 0x815a, 0x0150);
+		sram2_write(tp, 0x81f4, 0x0150);
+		sram2_write(tp, 0x828e, 0x0150);
+		sram2_write(tp, 0x81b1, 0x0000);
+		sram2_write(tp, 0x824b, 0x0000);
+		sram2_write(tp, 0x82e5, 0x0000);
+
+		sram2_write_w0w1(tp, 0x84f7, 0xff00, 0x2800);
+		ocp_reg_set_bits(tp, 0xaec2, BIT(12));
+		sram2_write_w0w1(tp, 0x81b3, 0xff00, 0xad00);
+		sram2_write_w0w1(tp, 0x824d, 0xff00, 0xad00);
+		sram2_write_w0w1(tp, 0x82e7, 0xff00, 0xad00);
+		ocp_reg_w0w1(tp, 0xae4e, 0x000f, 0x0001);
+		sram2_write_w0w1(tp, 0x82ce, 0xf000, 0x4000);
+
+		/* 5G shift sel, default = '04'
+		 * 10G shift sel, default = '03'
+		 */
+		sram2_write_w0w1(tp, 0x83a5, 0xff00, 0x0400);
+		sram2_write_w0w1(tp, 0x83a6, 0xff00, 0x0400);
+		sram2_write_w0w1(tp, 0x83a7, 0xff00, 0x0400);
+		sram2_write_w0w1(tp, 0x83a8, 0xff00, 0x0400);
+
+		/* XG INRX parameters
+		 * RC coefficients
+		 */
+		sram2_write(tp, 0x84ac, 0x0000);
+		sram2_write(tp, 0x84ae, 0x0000);
+		sram2_write(tp, 0x84b0, 0xf818);
+		sram2_write_w0w1(tp, 0x84b2, 0xff00, 0x6000);
+		/* Training AAGC PAR (with uc2 patch) */
+		sram2_write(tp, 0x8ffc, 0x6008);
+		sram2_write(tp, 0x8ffe, 0xf450);
+		/* DAC BGK */
+		sram2_write_w0w1(tp, 0x8015, 0, BIT(9));
+		sram2_write_w0w1(tp, 0x8016, 0, BIT(11));
+		sram2_write_w0w1(tp, 0x8fe6, 0xff00, 0x0800);
+		sram2_write(tp, 0x8fe4, 0x2114);
+		/* 10G PBO table */
+		sram2_write(tp, 0x8647, 0xa7b1);
+		sram2_write(tp, 0x8649, 0xbbca);
+		sram2_write_w0w1(tp, 0x864b, 0xff00, 0xdc00);
+		/* 2.5G ado power window size */
+		sram2_write_w0w1(tp, 0x8154, 0xc000, 0x4000);
+		sram2_write_w0w1(tp, 0x8158, 0xc000, 0);
+		/* 10G lock far */
+		sram2_write(tp, 0x826c, 0xffff);
+		sram2_write(tp, 0x826e, 0xffff);
+		/* XG INRX parameter */
+		sram2_write_w0w1(tp, 0x8872, 0xff00, 0x0e00);
+		sram_write_w0w1(tp, 0x8012, 0, BIT(11));
+		sram_write_w0w1(tp, 0x8012, 0, BIT(14));
+		ocp_reg_set_bits(tp, 0xb576, BIT(0));
+		sram_write_w0w1(tp, 0x834a, 0xff00, 0x0700);
+		sram2_write_w0w1(tp, 0x8217, 0x3f00, 0x2a00);
+		sram_write_w0w1(tp, 0x81b1, 0xff00, 0x0b00);
+		sram2_write_w0w1(tp, 0x8fed, 0xff00, 0x4e00);
+		/* Slave about EC mu of datamode AAGC  and DAC BG */
+		sram2_write_w0w1(tp, 0x88ac, 0xff00, 0x2300);
+		/* improve UBE */
+		ocp_reg_set_bits(tp, 0xbf0c, 0x7 << 11);
+		/* close Sparse NEC, improve connect 5EUU calble performace */
+		sram2_write_w0w1(tp, 0x88de, 0xff00, 0);
+		/* 5G slave compatibility issue (will include in v10) */
+		sram2_write(tp, 0x80b4, 0x5195);
+
+		/* XG Test Mode
+		 * xgtstm_map_tbl for mdi_cap_sel
+		 */
+		sram_write(tp, 0x8370, 0x8671);
+		sram_write(tp, 0x8372, 0x86c8);
+		/* xgtstm_amp_map_tbl for  REG_IBX_UP_SHIFT_L */
+		sram_write(tp, 0x8401, 0x86c8);
+		sram_write(tp, 0x8403, 0x86da);
+		sram_write_w0w1(tp, 0x8406, 0x1800, 0x1000);
+		sram_write_w0w1(tp, 0x8408, 0x1800, 0x1000);
+		sram_write_w0w1(tp, 0x840a, 0x1800, 0x1000);
+		sram_write_w0w1(tp, 0x840c, 0x1800, 0x1000);
+		sram_write_w0w1(tp, 0x840e, 0x1800, 0x1000);
+		sram_write_w0w1(tp, 0x8410, 0x1800, 0x1000);
+		sram_write_w0w1(tp, 0x8412, 0x1800, 0x1000);
+		sram_write_w0w1(tp, 0x8414, 0x1800, 0x1000);
+		sram_write_w0w1(tp, 0x8416, 0x1800, 0x1000);
+
+		/* Cable Test Patch */
+		sram_write(tp, 0x82bd, 0x1f40);
+
+		/* Thermal sensor parameters */
+		ocp_reg_w0w1(tp, 0xbfb4, 0x07ff, 0x0328);
+		ocp_reg_write(tp, 0xbfb6, 0x3e14);
+
+		/* spdchg_gtx_shape_100M */
+		ocp_reg_write(tp, OCP_SRAM_ADDR, 0x81c4);
+		ocp_reg_write(tp, OCP_SRAM_DATA, 0x003b);
+		ocp_reg_write(tp, OCP_SRAM_DATA, 0x0086);
+		ocp_reg_write(tp, OCP_SRAM_DATA, 0x00b7);
+		ocp_reg_write(tp, OCP_SRAM_DATA, 0x00db);
+		ocp_reg_write(tp, OCP_SRAM_DATA, 0x00fe);
+		ocp_reg_write(tp, OCP_SRAM_DATA, 0x00fe);
+		ocp_reg_write(tp, OCP_SRAM_DATA, 0x00fe);
+		ocp_reg_write(tp, OCP_SRAM_DATA, 0x00fe);
+		ocp_reg_write(tp, OCP_SRAM_DATA, 0x00c3);
+		ocp_reg_write(tp, OCP_SRAM_DATA, 0x0078);
+		ocp_reg_write(tp, OCP_SRAM_DATA, 0x0047);
+		ocp_reg_write(tp, OCP_SRAM_DATA, 0x0023);
+
+		/* lsbmsk_parameters
+		 * RL6961_lsbmsk_parameter_250207
+		 */
+		sram2_write(tp, 0x88d7, 0x01a0);
+		sram2_write(tp, 0x88d9, 0x01a0);
+		sram2_write(tp, 0x8ffa, 0x002a);
+
+		sram2_write(tp, 0x8fee, 0xffdf);
+		sram2_write(tp, 0x8ff0, 0xffff);
+		sram2_write(tp, 0x8ff2, 0x0a4a);
+		sram2_write(tp, 0x8ff4, 0xaa5a);
+		sram2_write(tp, 0x8ff6, 0x0a4a);
+		sram2_write(tp, 0x8ff8, 0xaa5a);
+
+		sram2_write_w0w1(tp, 0x88d5, 0xff00, 0x0200);
+		break;
+
 	default:
 		break;
 	}
@@ -8175,6 +8368,18 @@ static void r8157_hw_phy_cfg(struct r8152 *tp)
 	set_bit(PHY_RESET, &tp->flags);
 }
 
+static int r8159_wait_backup_restore(struct r8152 *tp)
+{
+	u32 ocp_data;
+
+	ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_MISC_0);
+	if (!(ocp_data & PCUT_STATUS))
+		return 0;
+
+	return poll_timeout_us(ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_GPHY_CTRL),
+			       ocp_data & BACKUP_RESTRORE, 200, 2000, false);
+}
+
 static void r8156_init(struct r8152 *tp)
 {
 	u32 ocp_data;
@@ -8184,14 +8389,14 @@ static void r8156_init(struct r8152 *tp)
 	if (test_bit(RTL8152_INACCESSIBLE, &tp->flags))
 		return;
 
-	if (tp->version == RTL_VER_16) {
+	if (tp->version == RTL_VER_16 || tp->version == RTL_VER_17) {
 		ocp_byte_set_bits(tp, MCU_TYPE_USB, 0xcffe, BIT(3));
 		ocp_byte_clr_bits(tp, MCU_TYPE_USB, 0xd3ca, BIT(0));
 	}
 
 	ocp_byte_clr_bits(tp, MCU_TYPE_USB, USB_ECM_OP, EN_ALL_SPEED);
 
-	if (tp->version != RTL_VER_16)
+	if (tp->version < RTL_VER_16)
 		ocp_write_word(tp, MCU_TYPE_USB, USB_SPEED_OPTION, 0);
 
 	ocp_word_set_bits(tp, MCU_TYPE_USB, USB_ECM_OPTION, BYPASS_MAC_RESET);
@@ -8205,6 +8410,7 @@ static void r8156_init(struct r8152 *tp)
 	case RTL_VER_13:
 	case RTL_VER_15:
 	case RTL_VER_16:
+	case RTL_VER_17:
 		r8156b_wait_loading_flash(tp);
 		break;
 	default:
@@ -8221,6 +8427,11 @@ static void r8156_init(struct r8152 *tp)
 			return;
 	}
 
+	if (tp->version == RTL_VER_17 && r8159_wait_backup_restore(tp)) {
+		dev_err(&tp->intf->dev, "init failed, backup-restore timed out\n");
+		return;
+	}
+
 	data = r8153_phy_status(tp, 0);
 	if (data == PHY_STAT_EXT_INIT) {
 		ocp_reg_clr_bits(tp, 0xa468, BIT(3) | BIT(1));
@@ -8236,7 +8447,7 @@ static void r8156_init(struct r8152 *tp)
 
 	data = r8153_phy_status(tp, PHY_STAT_LAN_ON);
 
-	if (tp->version == RTL_VER_16)
+	if (tp->version >= RTL_VER_16)
 		r8157_u2p3en(tp, false);
 	else
 		r8153_u2p3en(tp, false);
@@ -8247,7 +8458,7 @@ static void r8156_init(struct r8152 *tp)
 	/* U1/U2/L1 idle timer. 500 us */
 	ocp_write_word(tp, MCU_TYPE_USB, USB_U1U2_TIMER, 500);
 
-	if (tp->version == RTL_VER_16)
+	if (tp->version >= RTL_VER_16)
 		r8157_power_cut_en(tp, false);
 	else
 		r8153b_power_cut_en(tp, false);
@@ -8294,7 +8505,10 @@ static void r8156_init(struct r8152 *tp)
 	set_bit(GREEN_ETHERNET, &tp->flags);
 
 	/* rx aggregation / 16 bytes Rx descriptor */
-	if (tp->version == RTL_VER_16)
+	if (tp->version == RTL_VER_17)
+		ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_USB_CTRL,
+				  RX_AGG_DISABLE | RX_DESC_16B | BIT(11));
+	else if (tp->version == RTL_VER_16)
 		ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_USB_CTRL, RX_AGG_DISABLE | RX_DESC_16B);
 	else
 		ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_USB_CTRL, RX_AGG_DISABLE | RX_ZERO_EN);
@@ -8302,7 +8516,7 @@ static void r8156_init(struct r8152 *tp)
 	if (tp->version < RTL_VER_12)
 		ocp_byte_set_bits(tp, MCU_TYPE_USB, USB_BMU_CONFIG, ACT_ODMA);
 
-	if (tp->version == RTL_VER_16) {
+	if (tp->version >= RTL_VER_16) {
 		/* Disable Rx Zero Len */
 		rtl_bmu_clr_bits(tp, 0x2300, BIT(3));
 		/* TX descriptor Signature */
@@ -9690,6 +9904,29 @@ static int rtl_ops_init(struct r8152 *tp)
 		r8157_desc_init(tp);
 		break;
 
+	case RTL_VER_17:
+		tp->eee_en		= true;
+		tp->eee_adv		= MDIO_EEE_100TX | MDIO_EEE_1000T | MDIO_EEE_10GT;
+		tp->eee_adv2		= MDIO_EEE_2_5GT | MDIO_EEE_5GT;
+		ops->init		= r8156_init;
+		ops->enable		= rtl8156_enable;
+		ops->disable		= rtl8153_disable;
+		ops->up			= rtl8156_up;
+		ops->down		= rtl8156_down;
+		ops->unload		= rtl8153_unload;
+		ops->eee_get		= r8153_get_eee;
+		ops->eee_set		= r8152_set_eee;
+		ops->in_nway		= rtl8153_in_nway;
+		ops->hw_phy_cfg		= r8157_hw_phy_cfg;
+		ops->autosuspend_en	= rtl8157_runtime_enable;
+		ops->change_mtu		= rtl8156_change_mtu;
+		tp->rx_buf_sz		= 48 * 1024;
+		tp->support_2500full	= 1;
+		tp->support_5000full	= 1;
+		tp->support_10000full	= 1;
+		r8157_desc_init(tp);
+		break;
+
 	default:
 		ret = -ENODEV;
 		dev_err(&tp->intf->dev, "Unknown Device\n");
@@ -9843,6 +10080,9 @@ static u8 __rtl_get_hw_ver(struct usb_device *udev)
 	case 0x1030:
 		version = RTL_VER_16;
 		break;
+	case 0x2020:
+		version = RTL_VER_17;
+		break;
 	default:
 		version = RTL_VER_UNKNOWN;
 		dev_info(&udev->dev, "Unknown version 0x%04x\n", ocp_data);
@@ -10160,6 +10400,7 @@ static const struct usb_device_id rtl8152_table[] = {
 	{ USB_DEVICE(VENDOR_ID_REALTEK, 0x8155) },
 	{ USB_DEVICE(VENDOR_ID_REALTEK, 0x8156) },
 	{ USB_DEVICE(VENDOR_ID_REALTEK, 0x8157) },
+	{ USB_DEVICE(VENDOR_ID_REALTEK, 0x815a) },
 
 	/* Microsoft */
 	{ USB_DEVICE(VENDOR_ID_MICROSOFT, 0x07ab) },

-- 
2.47.3

Re: [PATCH net-next v2 2/4] r8152: Add support for the RTL8159 chip

[Jakub Kicinski]

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
r8152: Add support for the RTL8159 chip

This patch adds support for the Realtek RTL8159 as RTL_VER_17, reusing
large portions of the existing RTL8157 (RTL_VER_16) initialization and
USB power management paths. The bulk of the new code configures the
RTL8159 PHY inside r8157_hw_phy_cfg(), and a new USB product id 0x815a
is added to the device table.

>     r8152: Add support for the RTL8159 chip
>     
>     The RTL8157 re-uses the packet descriptor format introduced with the
>     RTL8157 and other hardware features of the RTL8157 (RTL_VER_16) such
>     as the SRAM access. The support therefore consists in expanding the
>     existing RTL8157 code for initialization and USB power management
>     to also be used for the RTL8159 (RTL_VER_17).

The commit subject says RTL8159 is being added, but the body reads
"The RTL8157 re-uses the packet descriptor format introduced with the
RTL8157 ..." and later "Add support for the USB device ID of Realtek
RTL8157-based adapters." Should these occurrences of RTL8157 actually
be RTL8159?

>     Most of the addiitonal code is added in r8157_hw_phy_cfg() to configure
                ^^^^^^^^^^

Typo: addiitonal.

>     Add support for the USB device ID of Realtek RTL8157-based adapters. Detect
>     the RTL8159 as RTL_VER_17 and set it up.

The new entry in rtl8152_table is 0x815a, which breaks the earlier
0x815N-for-RTL815N naming convention (0x8157 for RTL8157, etc.). Could
the commit message explain why the RTL8159 ships with product id
0x815a?

> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index 01e65d845f87..2a07dde289e2 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c

[ ... ]

> @@ -6894,7 +6903,7 @@ static void rtl8156_down(struct r8152 *tp)
>  			  PLA_MCU_SPDWN_EN);
>  
>  	r8153b_u1u2en(tp, false);
> -	if (tp->version != RTL_VER_16) {
> +	if (tp->version < RTL_VER_16) {
>  		r8153_u2p3en(tp, false);
>  		r8153b_power_cut_en(tp, false);
>  	}

rtl8156_down() is converted from "!= RTL_VER_16" to "< RTL_VER_16" so
that RTL_VER_17 takes the same path as RTL_VER_16. rtl8156_up() is
wired as ops->up for RTL_VER_17 in rtl_ops_init() but still uses
"!= RTL_VER_16" / "== RTL_VER_16" checks that were not converted.

In rtl8156_up():

	r8153b_u1u2en(tp, false);
	if (tp->version != RTL_VER_16)
		r8153_u2p3en(tp, false);
	...
	if (tp->version == RTL_VER_16)
		ocp_word_clr_bits(tp, MCU_TYPE_PLA, PLA_RCR1, BIT(3));
	...
	if (tp->version != RTL_VER_16)
		ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_SPEED_OPTION,
				  RG_PWRDN_EN | ALL_SPEED_OFF);
	...
	r8153_aldps_en(tp, true);
	if (tp->version != RTL_VER_16)
		r8153_u2p3en(tp, true);

	if (tp->version != RTL_VER_16 && tp->udev->speed >= USB_SPEED_SUPER)
		r8153b_u1u2en(tp, true);

Should these checks also be "< RTL_VER_16" for RTL_VER_17?

On RTL_VER_17 the up path will call r8153_u2p3en() (USB_U2P3_CTRL)
while r8156_init() and rtl8157_runtime_enable() route through
r8157_u2p3en() (USB_U2P3_V2_CTRL) - is that intentional, or should
RTL_VER_17 go through r8157_u2p3en() on up/down too?

Similarly, is the PLA_RCR1 BIT(3) clear needed on RTL_VER_17, and is
the re-enabling of r8153b_u1u2en(true) on up intended for the new
chip given the init path deliberately skips it for RTL_VER_16?

[ ... ]

> @@ -8140,6 +8149,190 @@ static void r8157_hw_phy_cfg(struct r8152 *tp)
>  		sram2_write_w0w1(tp, 0x807c, 0xff00, 0x5000);
>  		sram2_write_w0w1(tp, 0x809d, 0xff00, 0x5000);
>  		break;
> +
> +	case RTL_VER_17:

[ ... snipped, PHY register table ... ]

> +		break;
> +
>  	default:
>  		break;
>  	}
> @@ -8175,6 +8368,18 @@ static void r8157_hw_phy_cfg(struct r8152 *tp)
>  	set_bit(PHY_RESET, &tp->flags);
>  }
>  
> +static int r8159_wait_backup_restore(struct r8152 *tp)
> +{
> +	u32 ocp_data;
> +
> +	ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_MISC_0);
> +	if (!(ocp_data & PCUT_STATUS))
> +		return 0;
> +
> +	return poll_timeout_us(ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_GPHY_CTRL),
> +			       ocp_data & BACKUP_RESTRORE, 200, 2000, false);
> +}

The rest of the driver organizes helpers by chip family (r8152_,
r8153_, r8156_, r8157_) and the commit message describes the RTL8159
as reusing the RTL8157 scaffolding. Is the r8159_ prefix on this
single helper intentional, or would r8157_wait_backup_restore() (or
similar) fit better?

Also, poll_timeout_us() is invoked with a 200 us poll interval and a
2000 us overall timeout, giving roughly ten iterations before the
error path fires. Other GPHY-related waits in the driver allow up to
the order of seconds. Is 2 ms known to be sufficient for the
backup-restore handshake on RTL8159 across suspend/resume and on
slower hosts?

> @@ -8184,14 +8389,14 @@ static void r8156_init(struct r8152 *tp)
>  	if (test_bit(RTL8152_INACCESSIBLE, &tp->flags))
>  		return;
>  
> -	if (tp->version == RTL_VER_16) {
> +	if (tp->version == RTL_VER_16 || tp->version == RTL_VER_17) {
>  		ocp_byte_set_bits(tp, MCU_TYPE_USB, 0xcffe, BIT(3));
>  		ocp_byte_clr_bits(tp, MCU_TYPE_USB, 0xd3ca, BIT(0));
>  	}
>  
>  	ocp_byte_clr_bits(tp, MCU_TYPE_USB, USB_ECM_OP, EN_ALL_SPEED);
>  
> -	if (tp->version != RTL_VER_16)
> +	if (tp->version < RTL_VER_16)
>  		ocp_write_word(tp, MCU_TYPE_USB, USB_SPEED_OPTION, 0);

Later in the same function:

	if (tp->version != RTL_VER_16)
		ocp_word_clr_bits(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3,
				  PLA_MCU_SPDWN_EN);

Was this site meant to be converted to "< RTL_VER_16" along with the
others? As written, RTL_VER_17 clears PLA_MCU_SPDWN_EN during init,
while RTL_VER_16 does not.

[ ... ]

> @@ -8294,7 +8505,10 @@ static void r8156_init(struct r8152 *tp)
>  	set_bit(GREEN_ETHERNET, &tp->flags);
>  
>  	/* rx aggregation / 16 bytes Rx descriptor */
> -	if (tp->version == RTL_VER_16)
> +	if (tp->version == RTL_VER_17)
> +		ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_USB_CTRL,
> +				  RX_AGG_DISABLE | RX_DESC_16B | BIT(11));
> +	else if (tp->version == RTL_VER_16)
>  		ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_USB_CTRL, RX_AGG_DISABLE | RX_DESC_16B);

Every other USB_USB_CTRL bit written in this driver uses a named
macro (CDC_ECM_EN, RX_AGG_DISABLE, RX_ZERO_EN, RX_DESC_16B). Could
BIT(11) be given a symbolic name so future multi-version handling of
this register stays self-describing?

[ ... ]

> @@ -9690,6 +9904,29 @@ static int rtl_ops_init(struct r8152 *tp)
>  		r8157_desc_init(tp);
>  		break;
>  
> +	case RTL_VER_17:
> +		tp->eee_en		= true;
> +		tp->eee_adv		= MDIO_EEE_100TX | MDIO_EEE_1000T | MDIO_EEE_10GT;
> +		tp->eee_adv2		= MDIO_EEE_2_5GT | MDIO_EEE_5GT;
> +		ops->init		= r8156_init;
> +		ops->enable		= rtl8156_enable;
> +		ops->disable		= rtl8153_disable;
> +		ops->up			= rtl8156_up;
> +		ops->down		= rtl8156_down;

ops->up is wired to rtl8156_up() here, but rtl8156_up() still checks
for RTL_VER_16 exclusively at the sites noted above. See the
rtl8156_down() hunk for the pattern that appears to be intended.

> +		ops->unload		= rtl8153_unload;
> +		ops->eee_get		= r8153_get_eee;
> +		ops->eee_set		= r8152_set_eee;
> +		ops->in_nway		= rtl8153_in_nway;
> +		ops->hw_phy_cfg		= r8157_hw_phy_cfg;
> +		ops->autosuspend_en	= rtl8157_runtime_enable;
> +		ops->change_mtu		= rtl8156_change_mtu;
> +		tp->rx_buf_sz		= 48 * 1024;
> +		tp->support_2500full	= 1;
> +		tp->support_5000full	= 1;
> +		tp->support_10000full	= 1;
> +		r8157_desc_init(tp);
> +		break;

RTL_VER_17 sets rx_buf_sz to 48 KiB and enables support_10000full,
but the max_mtu switch in rtl8152_probe() does not include
RTL_VER_17:

	case RTL_VER_12:
	case RTL_VER_13:
	case RTL_VER_15:
	case RTL_VER_16:
		netdev->max_mtu = size_to_mtu(16 * 1024);
		break;
	...
	default:
		netdev->max_mtu = ETH_DATA_LEN;
		break;

Should RTL_VER_17 also select the 16 KiB max_mtu case so jumbo frames
are available on the new 10 Gbit chip?

Separately, rtl8156_enable() is set as ops->enable for RTL_VER_17 but
the USB_RX_AGGR_NUM reset is guarded by
"tp->version >= RTL_VER_12 && tp->version <= RTL_VER_16", so
RTL_VER_17 does not execute it. Is that intended given RTL_VER_17
otherwise shares the RTL_VER_16 descriptor/aggregation plumbing
(r8157_desc_init(), and the USB_USB_CTRL aggregation bits cleared in
r8156_init() for RTL_VER_17)?

[ ... ]

Re: [PATCH net-next v2 2/4] r8152: Add support for the RTL8159 chip

[Birger Koblitz]

On 01/05/2026 3:15 am, Jakub Kicinski wrote:
> The commit subject says RTL8159 is being added, but the body reads
> "The RTL8157 re-uses the packet descriptor format introduced with the
> RTL8157 ..." and later "Add support for the USB device ID of Realtek
> RTL8157-based adapters." Should these occurrences of RTL8157 actually
> be RTL8159?

Both are typos and RTL8159 was meant. Will be fixed in v3.

> 
>>      Most of the addiitonal code is added in r8157_hw_phy_cfg() to configure
>                  ^^^^^^^^^^
> 
> Typo: addiitonal.

Will fix.

> 
>>      Add support for the USB device ID of Realtek RTL8157-based adapters. Detect
>>      the RTL8159 as RTL_VER_17 and set it up.
> 
> The new entry in rtl8152_table is 0x815a, which breaks the earlier
> 0x815N-for-RTL815N naming convention (0x8157 for RTL8157, etc.). Could
> the commit message explain why the RTL8159 ships with product id
> 0x815a?

Will fix.

> 
>> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
>> index 01e65d845f87..2a07dde289e2 100644
>> --- a/drivers/net/usb/r8152.c
>> +++ b/drivers/net/usb/r8152.c
> 
> [ ... ]
> 
>> @@ -6894,7 +6903,7 @@ static void rtl8156_down(struct r8152 *tp)
>>   			  PLA_MCU_SPDWN_EN);
>>   
>>   	r8153b_u1u2en(tp, false);
>> -	if (tp->version != RTL_VER_16) {
>> +	if (tp->version < RTL_VER_16) {
>>   		r8153_u2p3en(tp, false);
>>   		r8153b_power_cut_en(tp, false);
>>   	}
> 
> rtl8156_down() is converted from "!= RTL_VER_16" to "< RTL_VER_16" so
> that RTL_VER_17 takes the same path as RTL_VER_16. rtl8156_up() is
> wired as ops->up for RTL_VER_17 in rtl_ops_init() but still uses
> "!= RTL_VER_16" / "== RTL_VER_16" checks that were not converted.

This was simply forgotten. The code-path for the RTL8159, i.e. 
RTL_VER_17 should be the same as for the RTL8157 (RTL_VER_16), will fix 
rtl8156_up() accordingly.

> The rest of the driver organizes helpers by chip family (r8152_,
> r8153_, r8156_, r8157_) and the commit message describes the RTL8159
> as reusing the RTL8157 scaffolding. Is the r8159_ prefix on this
> single helper intentional, or would r8157_wait_backup_restore() (or
> similar) fit better?

The prefix is intentional, since the function is only used for the
RTL8159.

> 
> Also, poll_timeout_us() is invoked with a 200 us poll interval and a
> 2000 us overall timeout, giving roughly ten iterations before the
> error path fires. Other GPHY-related waits in the driver allow up to
> the order of seconds. Is 2 ms known to be sufficient for the
> backup-restore handshake on RTL8159 across suspend/resume and on
> slower hosts?

Experimentally, the function returns always on the first iteration, 
which is the reason for the short poll interval. A safety factor of 10 
appears to be relatively generous. The out-of-tree code was busy waiting 
for 100 iterations without any delay. The polling in wait_cmd_ready() 
waits for up-to 20ms. Since it does not hurt and to be on the safe side, 
I will change the total poll time to 20ms, here, too.

> 
>> @@ -8184,14 +8389,14 @@ static void r8156_init(struct r8152 *tp)

> Later in the same function:
> 
> 	if (tp->version != RTL_VER_16)
> 		ocp_word_clr_bits(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3,
> 				  PLA_MCU_SPDWN_EN);
> 
> Was this site meant to be converted to "< RTL_VER_16" along with the
> others? As written, RTL_VER_17 clears PLA_MCU_SPDWN_EN during init,
> while RTL_VER_16 does not.

Indeed, this was an oversight, it should have been also converted to 
"<". Will fix.

> 
> [ ... ]
> 
>> @@ -8294,7 +8505,10 @@ static void r8156_init(struct r8152 *tp)
>>   	set_bit(GREEN_ETHERNET, &tp->flags);
>>   
>>   	/* rx aggregation / 16 bytes Rx descriptor */
>> -	if (tp->version == RTL_VER_16)
>> +	if (tp->version == RTL_VER_17)
>> +		ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_USB_CTRL,
>> +				  RX_AGG_DISABLE | RX_DESC_16B | BIT(11));
>> +	else if (tp->version == RTL_VER_16)
>>   		ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_USB_CTRL, RX_AGG_DISABLE | RX_DESC_16B);
> 
> Every other USB_USB_CTRL bit written in this driver uses a named
> macro (CDC_ECM_EN, RX_AGG_DISABLE, RX_ZERO_EN, RX_DESC_16B). Could
> BIT(11) be given a symbolic name so future multi-version handling of
> this register stays self-describing?

Unfortunately, BIT(11) just appears here, for the RTL8159 in the 
out-of-tree code, without any further explanation. For BIT(10) = 
RX_DESC_16B I guessed the name from the comment. That bit appears for 
both chips, but BIT(11) just is there for the RTL8159, while the comment 
stays the same. Any guess could turn out to be misleading.

> 
> [ ... ]
> 
>> @@ -9690,6 +9904,29 @@ static int rtl_ops_init(struct r8152 *tp)
>>   		r8157_desc_init(tp);
>>   		break;
>>   
>> +	case RTL_VER_17:
>> +		tp->eee_en		= true;
>> +		tp->eee_adv		= MDIO_EEE_100TX | MDIO_EEE_1000T | MDIO_EEE_10GT;
>> +		tp->eee_adv2		= MDIO_EEE_2_5GT | MDIO_EEE_5GT;
>> +		ops->init		= r8156_init;
>> +		ops->enable		= rtl8156_enable;
>> +		ops->disable		= rtl8153_disable;
>> +		ops->up			= rtl8156_up;
>> +		ops->down		= rtl8156_down;
> 
> ops->up is wired to rtl8156_up() here, but rtl8156_up() still checks
> for RTL_VER_16 exclusively at the sites noted above. See the
> rtl8156_down() hunk for the pattern that appears to be intended.

This is fixed, see above.

> RTL_VER_17 sets rx_buf_sz to 48 KiB and enables support_10000full,
> but the max_mtu switch in rtl8152_probe() does not include
> RTL_VER_17:
> 
> 	case RTL_VER_12:
> 	case RTL_VER_13:
> 	case RTL_VER_15:
> 	case RTL_VER_16:
> 		netdev->max_mtu = size_to_mtu(16 * 1024);
> 		break;
> 	...
> 	default:
> 		netdev->max_mtu = ETH_DATA_LEN;
> 		break;
> 
> Should RTL_VER_17 also select the 16 KiB max_mtu case so jumbo frames
> are available on the new 10 Gbit chip?

Yes, this was an oversight. Will be fixed.

> 
> Separately, rtl8156_enable() is set as ops->enable for RTL_VER_17 but
> the USB_RX_AGGR_NUM reset is guarded by
> "tp->version >= RTL_VER_12 && tp->version <= RTL_VER_16", so
> RTL_VER_17 does not execute it. Is that intended given RTL_VER_17
> otherwise shares the RTL_VER_16 descriptor/aggregation plumbing
> (r8157_desc_init(), and the USB_USB_CTRL aggregation bits cleared in
> r8156_init() for RTL_VER_17)?
> 
> [ ... ]
RTL_VER_17 should be included in that range. Will fix.

[PATCH net-next v2 3/4] r8152: Add irq mitigation for RTL8157/9

[Birger Koblitz]

Add interrupt mitigation code for both RTL8157 and RTL8159 that prevents
USB interrupt callbacks with urb->status ESHUTDOWN being triggered. While the
issue is rarely seen on the RTL8157, without the mitigation, it is
common on the RTL8159:
[273.561863] r8152 7-1:1.0 enx88c9b3b5xxxx: Stop submitting intr, status -108

Signed-off-by: Birger Koblitz <mail@birger-koblitz.de>
---
 drivers/net/usb/r8152.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 2a07dde289e2240b221664ae5c5bceec35b5a1ef..9fcad3dac76f8aa76ef074cabd3b08348dc234bc 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -8452,6 +8452,12 @@ static void r8156_init(struct r8152 *tp)
 	else
 		r8153_u2p3en(tp, false);
 
+	if (tp->version >= RTL_VER_16) {
+		/* Disable Interrupt Mitigation */
+		ocp_byte_clr_bits(tp, MCU_TYPE_USB, 0xcf04,
+				  BIT(0) | BIT(1) | BIT(2) | BIT(7));
+	}
+
 	/* MSC timer = 0xfff * 8ms = 32760 ms */
 	ocp_write_word(tp, MCU_TYPE_USB, USB_MSC_TIMER, 0x0fff);
 

-- 
2.47.3

Re: [PATCH net-next v2 3/4] r8152: Add irq mitigation for RTL8157/9

[Jakub Kicinski]

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
r8152: Add irq mitigation for RTL8157/9

This commit clears bits 0, 1, 2, and 7 of USB register 0xcf04 in
r8156_init() for RTL_VER_16 and later, with the stated intent of avoiding
intr URB completions with urb->status == -ESHUTDOWN on RTL8157 and
RTL8159.

> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index 2a07dde289e2..9fcad3dac76f 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -8452,6 +8452,12 @@ static void r8156_init(struct r8152 *tp)
>  	else
>  		r8153_u2p3en(tp, false);
>  
> +	if (tp->version >= RTL_VER_16) {
> +		/* Disable Interrupt Mitigation */
> +		ocp_byte_clr_bits(tp, MCU_TYPE_USB, 0xcf04,
> +				  BIT(0) | BIT(1) | BIT(2) | BIT(7));
> +	}
> +

The subject and changelog describe this as adding "irq mitigation" /
"interrupt mitigation code", but the in-tree comment says "Disable
Interrupt Mitigation" and the operation is ocp_byte_clr_bits(), which
turns a hardware feature off.

Would it be clearer to phrase the subject along the lines of "r8152:
disable hardware interrupt mitigation on RTL8157/9" so that someone
bisecting or searching the log for when this feature was "added" is not
led in the opposite direction?

The same sequence already exists in rtl8153_unload():

	static void rtl8153_unload(struct r8152 *tp)
	{
		if (test_bit(RTL8152_INACCESSIBLE, &tp->flags))
			return;

		r8153_power_cut_en(tp, false);

		if (tp->version >= RTL_VER_16) {
			/* Disable Interrupt Mitigation */
			ocp_byte_clr_bits(tp, MCU_TYPE_USB, 0xcf04, BIT(0) | BIT(1) | BIT(2) | BIT(7));
		}
	}

That copy was introduced by fd3c7d080df5 ("r8152: Add support for the
RTL8157 hardware"). Now that the bits are cleared during init, does the
unload-path copy still serve a purpose, or can it be removed as part of
this change?

The register 0xcf04 and the bit selection BIT(0) | BIT(1) | BIT(2) |
BIT(7) are bare numeric literals, while most of the file uses named
defines (USB_MSC_TIMER, USB_U2P3_CTRL, U2P3_ENABLE, and so on). Could
this change also introduce a symbolic name for the register and for the
individual bits being cleared, so reviewers can check the mask against
the datasheet and tell which bit is the enable versus threshold versus
reserved?

On the causal chain:

The changelog links the register write to intr URB completions with
status -ESHUTDOWN / -108, but does not explain how a MAC-side
interrupt-mitigation setting produces that status.

-ESHUTDOWN on an intr URB is normally posted by the USB core when an
endpoint has been disabled or the device is disconnecting. Could the
commit message describe the mechanism by which clearing these four bits
prevents the host controller from observing endpoint shutdown, and cite
the datasheet naming for bits 0, 1, 2, and 7 of 0xcf04 so it is clear
why exactly those bits (and no others) are the correct set to clear?

Re: [PATCH net-next v2 3/4] r8152: Add irq mitigation for RTL8157/9

[Birger Koblitz]

On 01/05/2026 3:16 am, Jakub Kicinski wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> ---
> r8152: Add irq mitigation for RTL8157/9
> 
> This commit clears bits 0, 1, 2, and 7 of USB register 0xcf04 in
> r8156_init() for RTL_VER_16 and later, with the stated intent of avoiding
> intr URB completions with urb->status == -ESHUTDOWN on RTL8157 and
> RTL8159.
Based on the discussion in the parallel thread with Andrew and Michal,
I will drop this part of the series, as the issue this patch tries to
address is harmless, better solved differently, and it affects 
performance. I will submit a separate patch as bug-fix to remove the 
same register settings done in rtl8153_unload(), as this also applies to 
the RTL8157.

[PATCH net-next v2 4/4] r8152: Add firmware upload capability for RTL8157/RTL8159

[Birger Koblitz]

The RTL8159 (RTL_VER_17) requires firmware for its PHY in order to work
at connection speeds > 5GBit. Add support for uploading firmware for
the PHY using the existing rtl8152_apply_firmware() function
in r8157_hw_phy_cfg() and set up the correct names for the firmware
files.

This also adds support for uploading firmware for the RTL8157
(RTL_VER_16) PHY, for which firmware is however not strictly necessary
to work. Still, this allows to upload newer versions of the firmware used
by this chip, e.g. to improve interoperability.

If no firmware is found, both the RTL8157 and the RTL8159 will continue
to work.

Signed-off-by: Birger Koblitz <mail@birger-koblitz.de>
---
 drivers/net/usb/r8152.c | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 9fcad3dac76f8aa76ef074cabd3b08348dc234bc..8d880afd88c9392cd873a5015a0d7feee538ac7f 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -4663,10 +4663,11 @@ static bool rtl8152_is_fw_phy_speed_up_ok(struct r8152 *tp, struct fw_phy_speed_
 	case RTL_VER_11:
 	case RTL_VER_12:
 	case RTL_VER_14:
-	case RTL_VER_16:
 		goto out;
 	case RTL_VER_13:
 	case RTL_VER_15:
+	case RTL_VER_16:
+	case RTL_VER_17:
 	default:
 		break;
 	}
@@ -7996,12 +7997,14 @@ static void r8157_hw_phy_cfg(struct r8152 *tp)
 	data = r8153_phy_status(tp, 0);
 	switch (data) {
 	case PHY_STAT_EXT_INIT:
+		rtl8152_apply_firmware(tp, true);
 		ocp_reg_clr_bits(tp, 0xa466, BIT(0));
 		ocp_reg_clr_bits(tp, 0xa468, BIT(3) | BIT(1));
 		break;
 	case PHY_STAT_LAN_ON:
 	case PHY_STAT_PWRDN:
 	default:
+		rtl8152_apply_firmware(tp, false);
 		break;
 	}
 
@@ -9949,6 +9952,8 @@ static int rtl_ops_init(struct r8152 *tp)
 #define FIRMWARE_8153C_1	"rtl_nic/rtl8153c-1.fw"
 #define FIRMWARE_8156A_2	"rtl_nic/rtl8156a-2.fw"
 #define FIRMWARE_8156B_2	"rtl_nic/rtl8156b-2.fw"
+#define FIRMWARE_8157_1		"rtl_nic/rtl8157-1.fw"
+#define FIRMWARE_8159_1		"rtl_nic/rtl8159-1.fw"
 
 MODULE_FIRMWARE(FIRMWARE_8153A_2);
 MODULE_FIRMWARE(FIRMWARE_8153A_3);
@@ -9957,6 +9962,8 @@ MODULE_FIRMWARE(FIRMWARE_8153B_2);
 MODULE_FIRMWARE(FIRMWARE_8153C_1);
 MODULE_FIRMWARE(FIRMWARE_8156A_2);
 MODULE_FIRMWARE(FIRMWARE_8156B_2);
+MODULE_FIRMWARE(FIRMWARE_8157_1);
+MODULE_FIRMWARE(FIRMWARE_8159_1);
 
 static int rtl_fw_init(struct r8152 *tp)
 {
@@ -9995,6 +10002,12 @@ static int rtl_fw_init(struct r8152 *tp)
 		rtl_fw->pre_fw		= r8153b_pre_firmware_1;
 		rtl_fw->post_fw		= r8153c_post_firmware_1;
 		break;
+	case RTL_VER_16:
+		rtl_fw->fw_name		= FIRMWARE_8157_1;
+		break;
+	case RTL_VER_17:
+		rtl_fw->fw_name		= FIRMWARE_8159_1;
+		break;
 	default:
 		break;
 	}

-- 
2.47.3

Re: [PATCH net-next v2 0/4] r8152: Add support for the RTL8159 10Gbit USB Ethernet chip

[Aleksander Jan Bajkowski]

Hi Birger,
I ran a few tests on the RTL8157 and RTL8159. The 1/2.5/5/10G link
establishes correctly. The device also behaves normally under iperf load.
Everything is working fine so far.

On 29/04/2026 19:01, Birger Koblitz wrote:
> Add support for the RTL8159, which is a 10GBit USB-Ethernet adapter
> chip in the RTL815x family of chips.
>
> The RTL8159 re-uses the frame descriptor format and SRAM2 access introduced
> with the RTL8157 as well as most of the setup and PM logic of the RTL8157.
>
> The module was tested with a Lekuo DR59R11 USB-C 10GbE Ethernet Adapter:
> [ 2502.906947] usb 2-1: new SuperSpeed USB device number 3 using xhci_hcd
> [ 2502.927859] usb 2-1: New USB device found, idVendor=0bda, idProduct=815a, bcdDevice=30.00
> [ 2502.927867] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=7
> [ 2502.927871] usb 2-1: Product: USB 10/100/1G/2.5G/5G/10G LAN
> [ 2502.927873] usb 2-1: Manufacturer: Realtek
> [ 2502.927875] usb 2-1: SerialNumber: 000388C9B3B5XXXX
> [ 2503.063745] r8152-cfgselector 2-1: reset SuperSpeed USB device number 3 using xhci_hcd
> [ 2503.123876] r8152 2-1:1.0: Requesting firmware: rtl_nic/rtl8159-1.fw
> [ 2503.126267] r8152 2-1:1.0: PHY firmware installed 0 to be loaded: 20
> [ 2503.156265] r8152 2-1:1.0: load rtl8159-1 v1 2026/01/01 successfully
> [ 2503.270729] r8152 2-1:1.0 eth0: v1.12.13
> [ 2503.289349] r8152 2-1:1.0 enx88c9b3b5xxxx: renamed from eth0
> [ 2507.777055] r8152 2-1:1.0 enx88c9b3b5xxxx: carrier on
>
> The RTL8159 adapter was tested against an AQC107 PCIe-card supporting
> 10GBit/s and an RTL8157 5Gbit USB-Ethernet adapter supporting 5GBit/s for
> performance, link speed and EEE negotiation. Using USB3.2 Gen 2 (20GBit) with
> the RTL8159 USB adapter and running iperf3 against the AQC107 PCIe
> card resulted in 8.96 Gbits/sec transfer speed.
>
> The code is based on the out-of-tree r8152 driver published by Realtek under
> the GPL.
>
> The RTL8159 requires firmware for the PHY in order to achieve a 10GBit link
> speed. Without firmware, only 5GBit were achieved. The firmware can be
> extracted from the out-of-tree r8152 driver-code where it is stored in the
> ram17 u8-array. Code is added to use the existing firmware upload mechanism
> of the driver for the RTL8157/9 PHY firmware code. The firmware will be
> submitted separately to linux-firmware.
>
> Signed-off-by: Birger Koblitz <mail@birger-koblitz.de>
Tested-by: Aleksander Jan Bajkowski <olek2@wp.pl>
> ---
> Changes in v2:
> - Correct formatting of comments
> - Order case statement values correctly
> - Add error message when backup-restore fails
> - Correct commit message of support for firmware upload
> - Link to v1: https://lore.kernel.org/r/20260428-rtl8159_net_next-v1-0-52d03927b46f@birger-koblitz.de
>
> ---
> Birger Koblitz (4):
>        r8152: Add support for 10Gbit Link Speeds and EEE
>        r8152: Add support for the RTL8159 chip
>        r8152: Add irq mitigation for RTL8157/9
>        r8152: Add firmware upload capability for RTL8157/RTL8159
>
>   drivers/net/usb/r8152.c | 336 ++++++++++++++++++++++++++++++++++++++++++++++--
>   1 file changed, 324 insertions(+), 12 deletions(-)
> ---
> base-commit: 35c2c39832e569449b9192fa1afbbc4c66227af7
> change-id: 20260427-rtl8159_net_next-4f778a614fa7
>
> Best regards,