On Fri, 13 Feb 2026 11:20:05 +0800 Howard Wang <[email protected]> wrote:
> This patch series introduces several updates to the net/r8169 driver. > > The changes are categorized as follows: > > 1. Bug Fixes: > - Fix a crash during RTL8168FP initialization due to a missing function > pointer. > - Fix incorrect bitwise logic for RTL8127 capabilities. > - Fix incorrect speed identification for RTL8168KB (it is a 1G device). > - Fix link status reporting issues regarding old mapping. > > 2. New Hardware Support: > - Add support for RTL8125K (2.5G). > - Add support for RTL9151 (2.5G). > - Add support for RTL8168KD (1G). > > 3. Hardware Configuration Updates: > - Update MCU and PHY configurations for RTL8125, RTL8126, and RTL8127 > series > to match the latest hardware specifications. > - Optimize Rx descriptor fetch numbers for RTL8126 and RTL8127 to improve > performance. > - Adjust jumbo frame size limits for non-1G cards. > > 4. Cleanup: > - Remove support for the unreleased test chip (CFG_METHOD_69) to simplify > the code. > > Howard Wang (13): > net/r8169: fix crash in RTL8168FP init > net/r8169: optimize Rx descriptor fetch number > net/r8169: add support for RTL8168KD > net/r8169: update hardware configurations for 8127 > net/r8169: adjust jumbo frame size limit for non-1G cards > net/r8169: remove support for CFG_METHOD_69 > net/r8169: update hardware configurations for 8126 > net/r8169: update hardware configurations for 8125 > net/r8169: add support for RTL9151 > net/r8169: add support for RTL8125K > net/r8169: fix one bug about RTL8168KB > net/r8169: ensure the old mapping is used > net/r8169: fix bitmask logic for RTL8127 > > drivers/net/r8169/base/rtl8125a_mcu.c | 128 +-- > drivers/net/r8169/base/rtl8125b_mcu.c | 56 +- > drivers/net/r8169/base/rtl8125bp_mcu.c | 17 +- > drivers/net/r8169/base/rtl8125cp.c | 36 + > drivers/net/r8169/base/rtl8125cp_mcu.c | 87 +- > drivers/net/r8169/base/rtl8125cp_mcu.h | 1 + > drivers/net/r8169/base/rtl8125d.c | 31 +- > drivers/net/r8169/base/rtl8125d_mcu.c | 605 +++++++---- > drivers/net/r8169/base/rtl8125d_mcu.h | 1 + > drivers/net/r8169/base/rtl8126a.c | 32 +- > drivers/net/r8169/base/rtl8126a_mcu.c | 689 +----------- > drivers/net/r8169/base/rtl8126a_mcu.h | 2 - > drivers/net/r8169/base/rtl8127.c | 15 +- > drivers/net/r8169/base/rtl8127_mcu.c | 1332 +++++++++++++++++------- > drivers/net/r8169/base/rtl8168fp.c | 1 + > drivers/net/r8169/base/rtl8168fp.h | 1 + > drivers/net/r8169/base/rtl8168fp_mcu.c | 6 + > drivers/net/r8169/base/rtl9151a.c | 87 ++ > drivers/net/r8169/base/rtl9151a.h | 10 + > drivers/net/r8169/base/rtl9151a_mcu.c | 53 + > drivers/net/r8169/meson.build | 2 + > drivers/net/r8169/r8169_compat.h | 10 +- > drivers/net/r8169/r8169_ethdev.c | 36 +- > drivers/net/r8169/r8169_ethdev.h | 3 + > drivers/net/r8169/r8169_fiber.c | 15 +- > drivers/net/r8169/r8169_hw.c | 239 +++-- > drivers/net/r8169/r8169_hw.h | 11 +- > drivers/net/r8169/r8169_phy.c | 54 +- > drivers/net/r8169/r8169_rxtx.c | 1 - > 29 files changed, 2058 insertions(+), 1503 deletions(-) > create mode 100644 drivers/net/r8169/base/rtl9151a.c > create mode 100644 drivers/net/r8169/base/rtl9151a.h > create mode 100644 drivers/net/r8169/base/rtl9151a_mcu.c > Looks good merged to next-net. I will take the suggestion from AI for one patch subject. If interested here is the verbose AI review. # DPDK net/r8169 Patchset v4 Review — Deep Dive **Series**: `[PATCH v4 01/13] net/r8169: ...` (13 patches) **Author**: Howard Wang `<[email protected]>` **Date**: 2026-02-13 --- ## Series Overview This 13-patch series covers the Realtek r8169 PMD with a mix of bug fixes, new device support, hardware config updates, and code cleanup: - **Bug fixes** (patches 1, 11, 12, 13): NULL pointer crash in RTL8168FP, incorrect RTL8168KB speed classification, stale link status after vendor driver init, and wrong bitmask logic in RTL8127 serdes. - **New device support** (patches 3, 9, 10): RTL8168KD (1G), RTL9151 (2.5G), RTL8125K (2.5G). - **Hardware config updates** (patches 4, 7, 8): MCU patches for 8127, 8126, 8125 families. - **Performance tuning** (patch 2): Rx descriptor fetch number optimization. - **Jumbo frame adjustment** (patch 5): Per-device max frame sizes for non-1G cards. - **Code removal** (patch 6): Drop CFG_METHOD_69 (test chip never released). --- ## Patches With Findings ### Patch 5: `net/r8169: adjust jumbo frame size limit for non-1G cards` **Warning — Missing CFG_METHOD_59 (RTL8168KD) in jumbo frame switch** The switch statement in `rtl_dev_infos_get()` lists the 16K-capable non-1G devices: ```c case CFG_METHOD_50: case CFG_METHOD_51: case CFG_METHOD_54: case CFG_METHOD_55: case CFG_METHOD_56: case CFG_METHOD_57: case CFG_METHOD_58: case CFG_METHOD_70: case CFG_METHOD_71: case CFG_METHOD_91: dev_info->max_rx_pktlen = JUMBO_FRAME_16K; ``` CFG_METHOD_59 (RTL8168KD, added in patch 3) is absent. If it's a 1G device using the 8125D base code, it may still benefit from the 16K path, or it may intentionally fall through to the 9K default. Either way, this should be clarified — the commit description says "For other non-1G cards, set the max size to 16K" but RTL8168KD is a 1G card, so the 9K default may be correct. Worth explicit confirmation. --- ### Patch 6: `net/r8169: remove support for CFG_METHOD_69` **Warning — Interaction with patch 2** Patch 2 modifies the `CFG_METHOD_69` case in `hw_init_rxcfg_8126a()` to use `Rx_Fetch_Number_20`, then patch 6 removes `CFG_METHOD_69` entirely including that same code path. The patches should apply cleanly in sequence, but this creates churn — patch 2's changes to the CFG_METHOD_69 path are immediately deleted by patch 6. This is not a correctness bug, but as a reviewer observation: reordering patches 2 and 6 (remove first, then tune the remaining methods) would reduce noise in the series. **Info — `CFG_METHOD_69` mapping to `CFG_METHOD_DEFAULT`** In `rtl_get_mac_version()`, the device ID `0x64800000` with `ic_version_id == 0x00000000` is remapped from `CFG_METHOD_69` to `CFG_METHOD_DEFAULT`. This means any hardware that previously matched this ID will now be treated as an unknown chip. This is intentional per the commit message (test chip not released), but worth noting that any such hardware in the field would lose functionality. --- ### Patch 9: `net/r8169: add support for RTL9151` **Error (Confidence ~60%) — `RTE_ASSERT` followed by guard in `rtl8125_get_mac_version_v2()`** ```c RTE_ASSERT(val32 != UINT_MAX && (val32 & RTL_R32(hw, TxConfig) & 0x7c800000) == 0x7c800000); if (val32 == UINT_MAX) return; ``` `RTE_ASSERT` is typically compiled out in release builds (`RTE_ASSERT` is a no-op unless `RTE_ENABLE_ASSERT` is defined). The logic here defensively checks `val32 == UINT_MAX` after the assert, which is good. However, if the assert fires in debug builds, it will abort before the graceful return path is reached. The assert also issues a second MMIO read (`RTL_R32(hw, TxConfig)`) inside the assert condition — this read happens only in debug builds and has a side effect (MMIO access). This is unusual and potentially confusing. **Suggested fix**: Move the MMIO cross-check outside the assert or just use a log warning: ```c if (val32 == UINT_MAX) return; /* Verify TxConfig signature matches V2 register layout */ if ((val32 & RTL_R32(hw, TxConfig) & 0x7c800000) != 0x7c800000) { PMD_INIT_LOG(WARNING, "TxConfigV2 signature mismatch"); return; } ``` **Warning — Missing `CFG_METHOD_60` in `r8169_compat.h` enumeration** Patch 9 adds `CFG_METHOD_60` in several places and `RTL9151A` to the chipset enum, but the `CFG_METHOD_60` enum value itself needs to exist in `r8169_compat.h`. It's not shown in the diff. This may exist in the base code already, or be added by a dependency — cannot verify from the patch alone, so noting it for completeness. **Warning — Missing release notes for new device (RTL9151)** Per AGENTS.md guidelines: "New drivers or subsystems must have release notes." The RTL9151 is a new device type being added to an existing driver. There are no doc changes in this patch or the series. A release notes entry should be added. **Warning — Missing `doc/guides/nics/features/r8169.ini` update** If RTL9151 has different feature support than existing devices, the features matrix should be updated. --- ### Patch 10: `net/r8169: add support for RTL8125K` **Warning — `CFG_METHOD_61` shares RAM code version with `CFG_METHOD_57`** ```c case CFG_METHOD_57: case CFG_METHOD_59: case CFG_METHOD_61: hw->sw_ram_code_ver = NIC_RAMCODE_VERSION_CFG_METHOD_57; break; ``` This is intentional (RTL8125K uses the same MCU firmware as RTL8125D rev 2), but it means the ram code version define is named after a different chip method. This is just informational — the code is correct. **Warning — Missing release notes for new device (RTL8125K)** Same as patch 9 — new device support should be noted in release notes. --- ### Patch 11: `net/r8169: fix one bug about RTL8168KB` **Warning — Subject line wording** "fix one bug about RTL8168KB" is vague. A more descriptive subject like `net/r8169: fix RTL8168KB speed classification` would better communicate what the patch does. --- ### Patch 13: `net/r8169: fix bitmask logic for RTL8127` **This is a genuine correctness bug fix — good catch by the author.** The original code: ```c val &= (BIT_13 | BIT_12 | BIT_1 | BIT_0); /* BUG: clears everything EXCEPT these bits */ val |= BIT_1; ``` The fix: ```c val &= ~(BIT_13 | BIT_12 | BIT_1 | BIT_0); /* Correct: clears these specific bits */ val |= BIT_1; ``` Without the `~`, the `&=` would mask the value to *only* keep bits 13, 12, 1, and 0, destroying all other bits in the register. With the fix, only the targeted bits are cleared before setting BIT_1. This would have caused incorrect serdes capability configuration for RTL8127 1G and 10G modes. The fix is correct. --- ## Patches With No Issues Patches 1, 2, 3, 4, 7, 8, 12 were reviewed and no issues requiring report were found. The bug fixes (1, 12) are straightforward and correct. The hardware config updates (3, 4, 7, 8) follow established patterns in the driver. Patch 2's register constant definitions (`Rx_Fetch_Number_12`, `Rx_Fetch_Number_20`) use existing macro patterns correctly. --- ## Summary | Severity | Count | Details | |----------|-------|---------| | Error | 1 | MMIO read inside `RTE_ASSERT` in patch 9 | | Warning | 5 | Missing release notes (9, 10), subject wording (11), CFG_METHOD_59 jumbo clarification (5), patch ordering churn (6) | | Info | 1 | CFG_METHOD_69 default remap (6) | The series is overall well-structured. The high-value finding is patch 13's bitmask fix which addresses a real hardware misconfiguration bug. The main areas for improvement are documentation (release notes for new devices) and minor commit message polish.
