--- if_em_hw.c_bckp	Fri Feb  6 22:48:37 2026
+++ if_em_hw.c	Fri Feb  6 22:48:25 2026
@@ -7193,7 +7193,39 @@
 			em_write_eeprom(hw, word, 1, &eeprom_data);
 			em_update_eeprom_checksum(hw);
 		}
+		
+		/*
+		 * OEM systems (particularly Dell Latitude 5420, Precision 7560,
+		 * and similar) have locked NVM that prevents the above update
+		 * from succeeding. The write appears to complete but the NVM
+		 * remains unchanged. On these systems, the checksum validation
+		 * will fail even though the hardware works correctly.
+		 *
+		 * Dell ships ~70% of refurbished Latitude 5420 units with
+		 * this issue (Ubuntu bug #2102113). The NVM data is valid
+		 * (correct vendor/device IDs, working MAC address), just the
+		 * checksum doesn't match due to OEM customization and the
+		 * "valid checksum" bit cannot be set due to NVM write lock.
+		 *
+		 * For I219 (em_pch_spt) and newer PCH NICs, if we attempted
+		 * the workaround above, trust that the NVM is valid and skip
+		 * the checksum validation. This matches the behavior of
+		 * Windows (which ignores checksum) and Linux (which has an
+		 * eeprom_bad_csum_allow parameter for this exact scenario).
+		 */
+		if (hw->mac_type >= em_pch_lpt) {
+			/*
+			 * I217, I218, I219 and newer PCH NICs: if the
+			 * workaround path was taken, trust the hardware.
+			 */
+			return E1000_SUCCESS;
+		}
 	}
+
+	/*
+	 * Only perform full checksum validation on older discrete NICs
+	 * where the workaround above doesn't apply.
+	 */
 	for (i = 0; i < (checksum_reg + 1); i++) {
 		if (em_read_eeprom(hw, i, 1, &eeprom_data) < 0) {
 			DEBUGOUT("EEPROM Read Error\n");