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

[PATCH net-next 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>
---
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 | 328 ++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 316 insertions(+), 12 deletions(-)
---
base-commit: 35c2c39832e569449b9192fa1afbbc4c66227af7
change-id: 20260427-rtl8159_net_next-4f778a614fa7

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

[PATCH net-next 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>
---
 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 1/4] r8152: Add support for 10Gbit Link Speeds and EEE

[Andrew Lunn]

On Tue, Apr 28, 2026 at 05:47:21AM +0200, Birger Koblitz wrote:
> 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>

    Andrew

[PATCH net-next 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 | 249 ++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 241 insertions(+), 8 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 01e65d845f8732f23427305423e4e270dae775dc..8255261d73148a7b4dabe0188faf07cb1f356437 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
 };
@@ -3431,6 +3432,7 @@ static void rtl8152_nic_reset(struct r8152 *tp)
 		ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_USB_CTRL, CDC_ECM_EN);
 		break;
 
+	case RTL_VER_17:
 	case RTL_VER_16:
 		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,184 @@ 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 +8362,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 +8383,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 +8404,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 +8421,9 @@ static void r8156_init(struct r8152 *tp)
 			return;
 	}
 
+	if (tp->version == RTL_VER_17 && r8159_wait_backup_restore(tp))
+		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 +8439,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 +8450,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 +8497,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 +8508,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 +9896,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 +10072,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 +10392,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 2/4] r8152: Add support for the RTL8159 chip

[Andrew Lunn]

> @@ -3431,6 +3432,7 @@ static void rtl8152_nic_reset(struct r8152 *tp)
>  		ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_USB_CTRL, CDC_ECM_EN);
>  		break;
>  
> +	case RTL_VER_17:
>  	case RTL_VER_16:
>  		ocp_byte_clr_bits(tp, MCU_TYPE_PLA, PLA_CR, CR_RE | CR_TE);

nitpick. The other switch statements seem to be sorted. So 17 should
be after 16.

> +		/* 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

normal? Please also add a space after the //. netdev also prefers /*
*/.

> +		/* 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)

space

> +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)
> @@ -8221,6 +8421,9 @@ static void r8156_init(struct r8152 *tp)
>  			return;
>  	}
>  
> +	if (tp->version == RTL_VER_17 && r8159_wait_backup_restore(tp))
> +		return;

You should probably do something with the return value from
r8159_wait_backup_restore(). At minimum a dev_err().

    Andrew

---
pw-bot: cr
	

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

[Birger Koblitz]

Hi Andrew,
thanks for reviewing!
On 29/04/2026 3:52 am, Andrew Lunn wrote:
>> +	case RTL_VER_17:
>>   	case RTL_VER_16:
>>   		ocp_byte_clr_bits(tp, MCU_TYPE_PLA, PLA_CR, CR_RE | CR_TE);
> 
> nitpick. The other switch statements seem to be sorted. So 17 should
> be after 16.
Will fix in the next version.

>> +		sram_write_w0w1(tp, 0x81b9, 0xff00, 0xb900);
>> +		//nomal link TX filter
> 
> normal? Please also add a space after the //. netdev also prefers /*
> */.
Will fix.

>> +		sram2_write_w0w1(tp, 0x84b2, 0xff00, 0x6000);
>> +		//Training AAGC PAR (with uc2 patch)
> 
> space
Will fix.

>> +	if (tp->version == RTL_VER_17 && r8159_wait_backup_restore(tp))
>> +		return;
> 
> You should probably do something with the return value from
> r8159_wait_backup_restore(). At minimum a dev_err().
> 
I will add a dev_err() message.

Birger

[PATCH net-next 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 8255261d73148a7b4dabe0188faf07cb1f356437..08cc3c1dae0facb2400890ba4d093c97ed56d40b 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -8444,6 +8444,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 3/4] r8152: Add irq mitigation for RTL8157/9

[Andrew Lunn]

On Tue, Apr 28, 2026 at 05:47:23AM +0200, Birger Koblitz wrote:
> 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 8255261d73148a7b4dabe0188faf07cb1f356437..08cc3c1dae0facb2400890ba4d093c97ed56d40b 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -8444,6 +8444,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));
> +	}

What does interrupt mitigation do?

Is this a different name for interrupt coalescence, where the MAC
delays interrupts for a period of time so more packets are in the
receive ring when it does interrupt, so reducing the number of
interrupts, and bigger bursts of packets are processed at once?

	Andrew

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

[Birger Koblitz]

On 29/04/2026 3:56 am, Andrew Lunn wrote:
> On Tue, Apr 28, 2026 at 05:47:23AM +0200, Birger Koblitz wrote:
>> 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 8255261d73148a7b4dabe0188faf07cb1f356437..08cc3c1dae0facb2400890ba4d093c97ed56d40b 100644
>> --- a/drivers/net/usb/r8152.c
>> +++ b/drivers/net/usb/r8152.c
>> @@ -8444,6 +8444,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));
>> +	}
> 
> What does interrupt mitigation do?
> 
> Is this a different name for interrupt coalescence, where the MAC
> delays interrupts for a period of time so more packets are in the
> receive ring when it does interrupt, so reducing the number of
> interrupts, and bigger bursts of packets are processed at once?
> 

I do not understand what the mechanism behind this is, there is no more
documentation in the original driver. I experimented with this for some
time and the effect that I see is that it prevents interrupts after
shutdown. That is, why it is already done in rtl8153_unload(), again 
like in the original driver, where it was more critical to prevent the 
warnings.
I was hoping that Realtek could enlighten us.

Birger

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

[Michal Pecio]

On Wed, 29 Apr 2026 06:06:30 +0200, Birger Koblitz wrote:
> On 29/04/2026 3:56 am, Andrew Lunn wrote:
> > On Tue, Apr 28, 2026 at 05:47:23AM +0200, Birger Koblitz wrote:  
> >> 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 8255261d73148a7b4dabe0188faf07cb1f356437..08cc3c1dae0facb2400890ba4d093c97ed56d40b 100644
> >> --- a/drivers/net/usb/r8152.c
> >> +++ b/drivers/net/usb/r8152.c
> >> @@ -8444,6 +8444,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));
> >> +	}  
> > 
> > What does interrupt mitigation do?
> > 
> > Is this a different name for interrupt coalescence, where the MAC
> > delays interrupts for a period of time so more packets are in the
> > receive ring when it does interrupt, so reducing the number of
> > interrupts, and bigger bursts of packets are processed at once?
> >   
> 
> I do not understand what the mechanism behind this is, there is no
> more documentation in the original driver. I experimented with this
> for some time and the effect that I see is that it prevents
> interrupts after shutdown.

What do you mean by "after shutdown", driver unbind? You shouldn't be
seeing URB completions then if the disconnect() method unlinks them.
And if it doesn't, completions may be using driver data after free.

Or maybe you have pending URBs while calling set_configuration() or
set_interface(), which is dodgy too but at least not asking for panic.

Other cause of ESHUTDOWN might be serious host controller failure, but
you would likely get other log noise with that, at least with xhci.

What shows up if you repro with this enabled?
echo 'module usbcore +p' >/proc/dynamic_debug/control

Regards,
Michal

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

[Birger Koblitz]

Thanks Michal, for your explanations!
On 29/04/2026 8:02 pm, Michal Pecio wrote:
>>> What does interrupt mitigation do?
>>>
>>> Is this a different name for interrupt coalescence, where the MAC
>>> delays interrupts for a period of time so more packets are in the
>>> receive ring when it does interrupt, so reducing the number of
>>> interrupts, and bigger bursts of packets are processed at once?
>>>    
>>
>> I do not understand what the mechanism behind this is, there is no
>> more documentation in the original driver. I experimented with this
>> for some time and the effect that I see is that it prevents
>> interrupts after shutdown.
> 
> What do you mean by "after shutdown", driver unbind? You shouldn't be
> seeing URB completions then if the disconnect() method unlinks them.
> And if it doesn't, completions may be using driver data after free.
> 
> Or maybe you have pending URBs while calling set_configuration() or
> set_interface(), which is dodgy too but at least not asking for panic.
> 
> Other cause of ESHUTDOWN might be serious host controller failure, but
> you would likely get other log noise with that, at least with xhci.
> 
> What shows up if you repro with this enabled?
> echo 'module usbcore +p' >/proc/dynamic_debug/control
> 

With shutdown, I meant shutting down the driver: the error happens when 
unloading the driver using rmmod, e.g. when testing different driver 
versions. What I see when turning on debugging is this:
[373042.499758] r8152 2-1:1.0 enx88c9b3b53125: carrier on
[373104.440114] usbcore: deregistering interface driver r8152
[373104.440141] xhci_hcd 0000:0c:00.0: shutdown urb 000000005501f8cc 
ep1in-bulk
[373104.440146] xhci_hcd 0000:0c:00.0: shutdown urb 0000000066ae4a92 
ep1in-bulk
[373104.440148] xhci_hcd 0000:0c:00.0: shutdown urb 00000000e9728025 
ep1in-bulk
[373104.440151] xhci_hcd 0000:0c:00.0: shutdown urb 00000000fa874ca0 
ep1in-bulk
[373104.440153] xhci_hcd 0000:0c:00.0: shutdown urb 000000006006ed5d 
ep1in-bulk
[373104.440156] xhci_hcd 0000:0c:00.0: shutdown urb 00000000a5bee1e7 
ep1in-bulk
[373104.440158] xhci_hcd 0000:0c:00.0: shutdown urb 00000000bc3a3ab0 
ep1in-bulk
[373104.440160] xhci_hcd 0000:0c:00.0: shutdown urb 0000000080a63692 
ep1in-bulk
[373104.440163] xhci_hcd 0000:0c:00.0: shutdown urb 0000000025af4e6e 
ep1in-bulk
[373104.440165] xhci_hcd 0000:0c:00.0: shutdown urb 0000000056d7e76e 
ep1in-bulk
[373104.440472] xhci_hcd 0000:0c:00.0: shutdown urb 00000000d8814536 
ep3in-intr
[373104.440790] r8152 2-1:1.0 enx88c9b3b53125: Stop submitting intr, 
status -108
[373104.479779] r8152 2-1:1.0: rtl8153_unload called
[373104.534682] usbcore: deregistering device driver r8152-cfgselector
[373104.534704] r8152-cfgselector 2-1: unregistering interface 2-1:1.0
[373104.534826] r8152-cfgselector 2-1: usb_disable_device nuking non-ep0 
URBs

In the past I have also seen the following, but am not able to reproduce it:
[371283.534041] r8152-cfgselector 2-1: USB disconnect, device number 25
[371283.534470] r8152 2-1:1.0 enx00e04c680023: Stop submitting intr, 
status -108

Also, I only see the issue on slow 5GBit USB-C connections, sometimes 
with the RTL8157, basically every time with the RTL8159, and so far 
never on a 20GBit USB-C connection, so the mitigation is probably some 
kind of interrupt coalescing.

Birger

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

[Michal Pecio]

On Thu, 30 Apr 2026 05:36:06 +0200, Birger Koblitz wrote:
> Thanks Michal, for your explanations!
> On 29/04/2026 8:02 pm, Michal Pecio wrote:
> >>> What does interrupt mitigation do?
> >>>
> >>> Is this a different name for interrupt coalescence, where the MAC
> >>> delays interrupts for a period of time so more packets are in the
> >>> receive ring when it does interrupt, so reducing the number of
> >>> interrupts, and bigger bursts of packets are processed at once?
> >>>      
> >>
> >> I do not understand what the mechanism behind this is, there is no
> >> more documentation in the original driver. I experimented with this
> >> for some time and the effect that I see is that it prevents
> >> interrupts after shutdown.  
> > 
> > What do you mean by "after shutdown", driver unbind? You shouldn't be
> > seeing URB completions then if the disconnect() method unlinks them.
> > And if it doesn't, completions may be using driver data after free.
> > 
> > Or maybe you have pending URBs while calling set_configuration() or
> > set_interface(), which is dodgy too but at least not asking for panic.
> > 
> > Other cause of ESHUTDOWN might be serious host controller failure, but
> > you would likely get other log noise with that, at least with xhci.
> > 
> > What shows up if you repro with this enabled?
> > echo 'module usbcore +p' >/proc/dynamic_debug/control
> >   
> 
> With shutdown, I meant shutting down the driver: the error happens when 
> unloading the driver using rmmod, e.g. when testing different driver 
> versions.

Sorry, I remembered wrong. That UAF problem only applies to control
URBs on endpoint 0. All other URBs are removed by USB core *before*
rtl8152_disconnect() is called. So it doesn't need to unlink them
and it cannot predict when the URBs will be nuked by core.

> What I see when turning on debugging is this:
> [373042.499758] r8152 2-1:1.0 enx88c9b3b53125: carrier on
> [373104.440114] usbcore: deregistering interface driver r8152
> [373104.440141] xhci_hcd 0000:0c:00.0: shutdown urb 000000005501f8cc 
> ep1in-bulk
> [373104.440146] xhci_hcd 0000:0c:00.0: shutdown urb 0000000066ae4a92 
> ep1in-bulk
> [373104.440148] xhci_hcd 0000:0c:00.0: shutdown urb 00000000e9728025 
> ep1in-bulk
> [373104.440151] xhci_hcd 0000:0c:00.0: shutdown urb 00000000fa874ca0 
> ep1in-bulk
> [373104.440153] xhci_hcd 0000:0c:00.0: shutdown urb 000000006006ed5d 
> ep1in-bulk
> [373104.440156] xhci_hcd 0000:0c:00.0: shutdown urb 00000000a5bee1e7 
> ep1in-bulk
> [373104.440158] xhci_hcd 0000:0c:00.0: shutdown urb 00000000bc3a3ab0 
> ep1in-bulk
> [373104.440160] xhci_hcd 0000:0c:00.0: shutdown urb 0000000080a63692 
> ep1in-bulk
> [373104.440163] xhci_hcd 0000:0c:00.0: shutdown urb 0000000025af4e6e 
> ep1in-bulk
> [373104.440165] xhci_hcd 0000:0c:00.0: shutdown urb 0000000056d7e76e 
> ep1in-bulk
> [373104.440472] xhci_hcd 0000:0c:00.0: shutdown urb 00000000d8814536 
> ep3in-intr

And that's what happens in the log above, for the reason below:

[  +0,000015]  usb_hcd_flush_endpoint.cold+0xa/0x23 [usbcore]
[  +0,000050]  usb_disable_endpoint+0x52/0xa0 [usbcore]
[  +0,000048]  usb_disable_interface.cold+0x3f/0x4e [usbcore]
[  +0,000038]  usb_unbind_interface+0x138/0x2f0 [usbcore]
[  +0,000048]  device_release_driver_internal+0x194/0x200

> [373104.440790] r8152 2-1:1.0 enx88c9b3b53125: Stop submitting intr, 
> status -108

So this message is harmless. I'm also seeing it with RTL8153 if the
interface is up at the time of rmmod.

> In the past I have also seen the following, but am not able to reproduce it:
> [371283.534041] r8152-cfgselector 2-1: USB disconnect, device number 25
> [371283.534470] r8152 2-1:1.0 enx00e04c680023: Stop submitting intr, 
> status -108

Apparently the disconnect message is logged before calling
rtl8152_disconnect(), so that's probably harmless too.

I'm not sure how tweaking some HW registers prevents it. Maybe it
causes the HW to complete the URB (but why?) at the right moment so
that it isn't pending during usb_disable_endpoint(), IDK, weird.

Regards,
Michal

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

[Andrew Lunn]

> Also, I only see the issue on slow 5GBit USB-C connections, sometimes with
> the RTL8157, basically every time with the RTL8159, and so far never on a
> 20GBit USB-C connection, so the mitigation is probably some kind of
> interrupt coalescing.

Do you notice any latency changes with this setting in place? Or CPU load.

ping can be a good measure for latency.

If this is interrupt coalescing, it normally means don't interrupt as
soon as one packet has been received. Delay the interrupt, so there
are likely to be more packets in the receive queue. The cost of the
interrupt handling is then spread over a number of packets.

If this register setting is disabling coalescing, you should see the
latency go down, but the CPU load go up.

If you are getting interrupts after the device has been disabled, i
guess it is because the timer for a delayed interrupt is not cancelled
by the firmware. If so you might be able to work around this firmware
bug. Disable the receiver, sleep for 10ms but keep processing
interrupts, and then continue with the tear down.

	Andrew

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

[Michal Pecio]

On Thu, 30 Apr 2026 16:19:30 +0200, Andrew Lunn wrote: 
> If you are getting interrupts after the device has been disabled, i
> guess it is because the timer for a delayed interrupt is not cancelled
> by the firmware. If so you might be able to work around this firmware
> bug. Disable the receiver, sleep for 10ms but keep processing
> interrupts, and then continue with the tear down.

If the device responded to this URB, it would complete with a normal
status (success or some USB error). ESHUTDOWN (and the debug log)
indicate that the URB was unlinked by USB core due to rmmod, before 
the driver knew that it's being unloaded and disabled anything.

Regards,
Michal

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

[Birger Koblitz]

Hi Andrew,

thanks a lot for the explanation of the USB-IRQ handling, that was very 
valuable for my understanding!
On 30/04/2026 4:19 pm, Andrew Lunn wrote:
>> Also, I only see the issue on slow 5GBit USB-C connections, sometimes with
>> the RTL8157, basically every time with the RTL8159, and so far never on a
>> 20GBit USB-C connection, so the mitigation is probably some kind of
>> interrupt coalescing.
> 
> Do you notice any latency changes with this setting in place? Or CPU load.
> 
> ping can be a good measure for latency.
I do not see any differences in latency. I am using 2 desktop machines 
for testing:
Machine 1: 6-core, 20GBit USB-C, RTL8159, Completely idle desktop
Machine 2: 8-core, AQC107 on PCIe5x, Desktop with dev-tools and Browser

All measurements for CPU-load and timing are done on Machine 1, which 
runs the iperf3-client and ping against Machine 2. There is a direct 
10GBit CAT6 link without any switch in between the RTL8159 and AQC107.

Ping times, WITH mitigation CODE (saying it disables mitigation):
--- 192.168.3.1 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 101342ms
rtt min/avg/max/mdev = 0.161/0.411/1.267/0.231 ms

Ping times, WITHOUT mitigation-CODE (saying it disabled mitigation):
--- 192.168.3.1 ping statistics ---
150 packets transmitted, 150 received, 0% packet loss, time 152451ms
rtt min/avg/max/mdev = 0.165/0.388/1.048/0.236 ms

Results are identical within statistical errors.

However, there is a big difference in CPU-load when running iperf3, 
especially with multiple threads:

WITH the CODE saying it disables IRQ mitigation:
$ iperf3 -c 192.168.3.1
[  5] 0.00-10.00  sec  10.3 GBytes  8.83 Gbits/sec
CPU: iperf3 22.5% ksoftirqd 16.6%

$ iperf3 -c 192.168.3.1 -P4
[SUM]   0.00-10.00  sec  9.36 GBytes  8.04 Gbits/sec
perf3: 19.3% ksoftirqd 96.7%


WITHOUT the CODE saying it disabled IRQ mitigation:
[  5]   0.00-10.00  sec  10.3 GBytes  8.87 Gbits/sec
CPU: perf3 19.7% ksoftirqd 12.5%

$ iperf3 -c 192.168.3.1 -P4
[SUM]   0.00-10.00  sec  10.3 GBytes  8.81 Gbits/sec
CPU: iperf3 22.0% ksoftirqd 46.5%

> 
> If this is interrupt coalescing, it normally means don't interrupt as
> soon as one packet has been received. Delay the interrupt, so there
> are likely to be more packets in the receive queue. The cost of the
> interrupt handling is then spread over a number of packets.
> 
> If this register setting is disabling coalescing, you should see the
> latency go down, but the CPU load go up.
I see the latency staying the same, but the CPU load goes up 
considerably when these register settings are done.

> 
> If you are getting interrupts after the device has been disabled, i
> guess it is because the timer for a delayed interrupt is not cancelled
> by the firmware. If so you might be able to work around this firmware
> bug. Disable the receiver, sleep for 10ms but keep processing
> interrupts, and then continue with the tear down.
> 
My undestanding from the first email by Michal is that the behavior with 
the ESHUTOWN is actually harmless and has been seen in the driver 
already for the RTL8153.

So, my suggestion is I drop this part of the patch-series and remove the 
IRQ-mitigation code that says it disables the IRQ mitigation as 
performance is higher without that code. The issue with ESHUTDOWN in the 
URB handler is a mostly unrelated issue that is probably harmless and 
can be solved separately.

Birger

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

[Andrew Lunn]

> However, there is a big difference in CPU-load when running iperf3,
> especially with multiple threads:
> 
> WITH the CODE saying it disables IRQ mitigation:
> $ iperf3 -c 192.168.3.1
> [  5] 0.00-10.00  sec  10.3 GBytes  8.83 Gbits/sec
> CPU: iperf3 22.5% ksoftirqd 16.6%
> 
> $ iperf3 -c 192.168.3.1 -P4
> [SUM]   0.00-10.00  sec  9.36 GBytes  8.04 Gbits/sec
> perf3: 19.3% ksoftirqd 96.7%
> 
> 
> WITHOUT the CODE saying it disabled IRQ mitigation:
> [  5]   0.00-10.00  sec  10.3 GBytes  8.87 Gbits/sec
> CPU: perf3 19.7% ksoftirqd 12.5%
> 
> $ iperf3 -c 192.168.3.1 -P4
> [SUM]   0.00-10.00  sec  10.3 GBytes  8.81 Gbits/sec
> CPU: iperf3 22.0% ksoftirqd 46.5%

Thanks for doing this performance testing.


> My undestanding from the first email by Michal is that the behavior with the
> ESHUTOWN is actually harmless and has been seen in the driver already for
> the RTL8153.
> 
> So, my suggestion is I drop this part of the patch-series and remove the
> IRQ-mitigation code that says it disables the IRQ mitigation as performance
> is higher without that code.

Agreed.

	Andrew

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

[Birger Koblitz]

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

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 08cc3c1dae0facb2400890ba4d093c97ed56d40b..56e00fe6f32405ce753df3e03e54a7daaf1a29ac 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;
 	}
 
@@ -9941,6 +9944,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);
@@ -9949,6 +9954,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)
 {
@@ -9987,6 +9994,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 4/4] r8152: Add firmware upload capability for RTL8157/RTL8159

[Andrew Lunn]

On Tue, Apr 28, 2026 at 05:47:24AM +0200, Birger Koblitz wrote:
> The RTL8159 requires firmware for its PHY in order to work at
> connection speeds > 5GBit. Add support for uploading firmware for
> the PHYs using the existing rtl8152_apply_firmware() function
> in r8157_hw_phy_cfg() and set up the correct names for the firmware
> files.
> 
> 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 08cc3c1dae0facb2400890ba4d093c97ed56d40b..56e00fe6f32405ce753df3e03e54a7daaf1a29ac 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:

Is that a bug fix?

	Andrew

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

[Birger Koblitz]

On 29/04/2026 3:57 am, Andrew Lunn wrote:
> On Tue, Apr 28, 2026 at 05:47:24AM +0200, Birger Koblitz wrote:
>> The RTL8159 requires firmware for its PHY in order to work at
>> connection speeds > 5GBit. Add support for uploading firmware for
>> the PHYs using the existing rtl8152_apply_firmware() function
>> in r8157_hw_phy_cfg() and set up the correct names for the firmware
>> files.
>>
>> 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 08cc3c1dae0facb2400890ba4d093c97ed56d40b..56e00fe6f32405ce753df3e03e54a7daaf1a29ac 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:
> 
> Is that a bug fix?
> 
> 	Andrew
No, since the RTL8157 (RTL_VER_16) also works in my experiments as 
expected without this change, i.e. without any updated firmware, or 
better the possibility to update the firmware. It is only for the 
RTL8159 where the firmware is necessary to even get 10GBit performance, 
at least for the link-partners I use for testing. My understanding of 
the Realtek "firmware" is that it mainly provides updated calibration 
constants, possibly better calibration routines for interoperability. 
Unlike for many other drivers, the firmware is not necessary to make the 
driver work at all.

Birger

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

[Andrew Lunn]

On Wed, Apr 29, 2026 at 06:21:58AM +0200, Birger Koblitz wrote:
> On 29/04/2026 3:57 am, Andrew Lunn wrote:
> > On Tue, Apr 28, 2026 at 05:47:24AM +0200, Birger Koblitz wrote:
> > > The RTL8159 requires firmware for its PHY in order to work at
> > > connection speeds > 5GBit. Add support for uploading firmware for
> > > the PHYs using the existing rtl8152_apply_firmware() function
> > > in r8157_hw_phy_cfg() and set up the correct names for the firmware
> > > files.

> No, since the RTL8157 (RTL_VER_16) also works in my experiments as expected
> without this change, i.e. without any updated firmware, or better the
> possibility to update the firmware. It is only for the RTL8159 where the
> firmware is necessary to even get 10GBit performance, at least for the
> link-partners I use for testing. My understanding of the Realtek "firmware"
> is that it mainly provides updated calibration constants, possibly better
> calibration routines for interoperability. Unlike for many other drivers,
> the firmware is not necessary to make the driver work at all.

O.K. Please could you expand the commit message. Explain why you are
adding code for RTL_VER_16 as well as RTL_VER_17.

	Andrew

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

[Birger Koblitz]

On 29/04/2026 3:01 pm, Andrew Lunn wrote:
> On Wed, Apr 29, 2026 at 06:21:58AM +0200, Birger Koblitz wrote:
>> On 29/04/2026 3:57 am, Andrew Lunn wrote:
>>> On Tue, Apr 28, 2026 at 05:47:24AM +0200, Birger Koblitz wrote:
>>>> The RTL8159 requires firmware for its PHY in order to work at
>>>> connection speeds > 5GBit. Add support for uploading firmware for
>>>> the PHYs using the existing rtl8152_apply_firmware() function
>>>> in r8157_hw_phy_cfg() and set up the correct names for the firmware
>>>> files.
> 
>> No, since the RTL8157 (RTL_VER_16) also works in my experiments as expected
>> without this change, i.e. without any updated firmware, or better the
>> possibility to update the firmware. It is only for the RTL8159 where the
>> firmware is necessary to even get 10GBit performance, at least for the
>> link-partners I use for testing. My understanding of the Realtek "firmware"
>> is that it mainly provides updated calibration constants, possibly better
>> calibration routines for interoperability. Unlike for many other drivers,
>> the firmware is not necessary to make the driver work at all.
> 
> O.K. Please could you expand the commit message. Explain why you are
> adding code for RTL_VER_16 as well as RTL_VER_17.
>I will update the commit message accordingly.

Birger