On 22.04.2025 10:43, Jacek Kowalski wrote:
Some Dell Tiger Lake systems have incorrect NVM checksum. These also
have a bitmask that indicates correct checksum set to "invalid".
Because it is impossible to determine whether the NVM write would finish
correctly or hang (see https://bugzilla.kernel.org/show_bug.cgi?id=213667)
it makes sense to skip the validation completely under these conditions.
Signed-off-by: Jacek Kowalski <[email protected]>
Fixes: 4051f68318ca9 ("e1000e: Do not take care about recovery NVM
checksum")
Cc: [email protected]
---
drivers/net/ethernet/intel/e1000e/ich8lan.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c
b/drivers/net/ethernet/intel/e1000e/ich8lan.c
index 364378133526..df4e7d781cb1 100644
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
@@ -4274,6 +4274,8 @@ static s32
e1000_validate_nvm_checksum_ich8lan(struct e1000_hw *hw)
ret_val = e1000e_update_nvm_checksum(hw);
if (ret_val)
return ret_val;
+ } else if (hw->mac.type == e1000_pch_tgp) {
+ return 0;
}
}
This patch doesn't work for me on an Optiplex 5090 Micro (i5-10500T). I
did some debugging and the platform is recognized as Tiger Lake, by the
driver, but the checksum valid bit is set even though the checksum is
not valid.
The network controller works fine if I patch out the validation in
netdev.c. The checksum word at address 0x7e read using ethtool is 0xffff.
I'm also a bit confused about why the driver reports the mac type as
e1000_pch_tgp even though i5-10500T should be Comet Lake?
