On 2/5/2026 11:26 AM, Kohei Enju wrote:
On Thu, 5 Feb 2026 11:16:50 +0200, "Lifshits, Vitaly" wrote:
On 2/5/2026 10:50 AM, Kohei Enju wrote:
On devices without NVM, hw->nvm.ops.validate is set to NULL, therefore
functions that perform EEPROM-related operations such as
igc_ethtool_set_eeprom() and igc_probe() check for NVM presence in
advance. However igc_eeprom_test() unconditionally calls
hw->nvm.ops.validate(), potentially causing a null pointer dereference.
NVM-less devices may not be common but possible, so add NULL check
before calling hw->nvm.ops.validate().
Fixes: f026d8ca2904 ("igc: add support to eeprom, registers and link
self-tests")
Signed-off-by: Kohei Enju <[email protected]>
---
drivers/net/ethernet/intel/igc/igc_diag.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/igc/igc_diag.c
b/drivers/net/ethernet/intel/igc/igc_diag.c
index a43d7244ee70..973d26a5a6c9 100644
--- a/drivers/net/ethernet/intel/igc/igc_diag.c
+++ b/drivers/net/ethernet/intel/igc/igc_diag.c
@@ -158,7 +158,7 @@ bool igc_eeprom_test(struct igc_adapter *adapter, u64 *data)
*data = 0;
- if (hw->nvm.ops.validate(hw) != IGC_SUCCESS) {
+ if (hw->nvm.ops.validate && hw->nvm.ops.validate(hw) != IGC_SUCCESS) {
*data = 1;
return false;
}
Hi Kohei,
Thank you for your patch.
Since there are no NVM-less devices I suggest removing the flash-less
code entirely from the init flow.
Oh, I see there're no NVM-less devices. Then removing sounds good to me.
Could you clarify what you mean by "init flow"? Do you mean removing
only the flash-less branch in igc_init_nvm_params_i225(), or removing
all flash-less related code including igc_get_flash_presence_i225() and
its callers?
After clarification, I'd love to work on it. Thank you for taking a
look!
No, you shouldn’t remove this function.
However, if for any reason the flash is not present, the driver should
fail initialization.
There are two related places that need to be updated to enforce this:
igc_probe() in igc_main.c
igc_init_nvm_params_i225() in igc_i225.c
This way we avoid supporting a configuration that doesn’t exist, and we
prevent the driver from partially initializing in an invalid state.
