[PATCH v4 16/20] net/txgbe: fix SFP module identification
Zaiyu Wang
zaiyuwang at trustnetic.com
Wed May 27 13:21:24 CEST 2026
> ## Errors
>
> ### 1. Resource leak in `txgbe_identify_sfp_module()` - multiple error paths
> missing unlock
No code change
The review is incorrect — all error paths after acquiring the lock do properly release it. There is no lock leak.
> ### 2. `txgbe_write_i2c_byte()` removes STOP condition - probable hardware
No code change
This change was ported from our out‑of‑tree Linux kernel driver. It was found that the previous write_i2c interface had problems, which caused ethtool -m to read some 40G optical module information incorrectly. Removing the intermediate STOP is intentional and fixes that issue.
> ### 3. Removed validation logic without replacement - SFP vendor checking
No code change
The old code was inherited from the Intel driver. The restriction has been removed intentionally: the driver now supports all optical modules that comply with the relevant standards, without limiting to a specific vendor.
> ## Warnings
>
> ### 1. `txgbe_identify_qsfp_module()` GPIO config runs unconditionally
No code change.
The function txgbe_identify_qsfp_module is only called for the Amber‑Lite 40G NIC. Among the three NIC types supported by txgbe (Sapphire 10G, Amber‑Lite 25G, Amber‑Lite 40G), only the 40G variant uses QSFP; the other two use SFP. Based on the aml40 hardware design, we need to configure the GPIO before using I2C.
> ### 2. Missing error propagation - `txgbe_read_i2c_sff8636()` page select failure
> ignored
Fixed.
> ### 3. Implicit comparison on pointer
Fixed.
> ### 5. Function pointer assignments removed but functions still defined
Already verified.
More information about the dev
mailing list