Skip to contentSkip to conversation

fm10k: don't continue probe if PCI device not in normal IO state

PATCH Superseded Jacob Keller 3 participants 3 messages Jun 14, 2016 – Jun 23, 2016

Subsystems (2)

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 fm10k: don't continue probe if PCI device not in normal IO state

In the event of an uncorrectable AER error occuring when the driver has not loaded, the recovery routines are not done. This is done because future loads of the driver may not be aware of the IO state and may not be able to recover at all. In this case, when we next load the driver it fails due to what appears to be a surprise remove event. Instead, add a check to ensure that the device is in the normal IO state before continuing to probe. This allows us to give a more descriptive message of what is wrong.

Without this change, the driver will attempt to probe up to our first call of .reset_hw() which will be unable to read registers and act as if a surprise remove event occurred.

---
 drivers/net/ethernet/intel/fm10k/fm10k_pci.c | 6 ++++++
 1 file changed, 6 insertions(+)
drivers/net/ethernet/intel/fm10k/fm10k_pci.c +6 -0
index b0c3d7b3a34c..e23923729541 100644
@@ -1950,6 +1950,12 @@ static int fm10k_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
 	struct fm10k_intfc *interface;
 	int err;
 
+	if (pdev->error_state != pci_channel_io_normal) {
+		dev_err(&pdev->dev,
+			"PCI device still in an error state. Unable to load...\n");
+		return -EIO;
+	}
+
 	err = pci_enable_device_mem(pdev);
 	if (err) {
 		dev_err(&pdev->dev,
Signature · 1 line
2.9.0.rc1.405.g81f467e
#1 lore raw

PATCH 1/1 fm10k: don't continue probe if PCI device not in normal IO state

Quoted 9 lines · Jacob Keller

In the event of an uncorrectable AER error occuring when the driver has not loaded, the recovery routines are not done. This is done because future loads of the driver may not be aware of the IO state and may not be able to recover at all. In this case, when we next load the driver it fails due to what appears to be a surprise remove event. Instead, add a check to ensure that the device is in the normal IO state before continuing to probe. This allows us to give a more descriptive message of what is wrong.

Quoted 8 lines

Without this change, the driver will attempt to probe up to our first call of .reset_hw() which will be unable to read registers and act as if a surprise remove event occurred.

---
?drivers/net/ethernet/intel/fm10k/fm10k_pci.c | 6 ++++++ ?1 file changed, 6 insertions(+)

This does not apply at all, the code was already removed in a previous
patch. ?So I am dropping this patch.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20160622/926489df/attachment.asc>

#2 lore raw

PATCH 1/1 fm10k: don't continue probe if PCI device not in normal IO state

Quoted 22 lines · Jeff Kirsher
Quoted 21 lines · Jacob Keller

In the event of an uncorrectable AER error occuring when the driver has
not loaded, the recovery routines are not done. This is done because
future loads of the driver may not be aware of the IO state and may not
be able to recover at all. In this case, when we next load the driver it
fails due to what appears to be a surprise remove event. Instead, add
a check to ensure that the device is in the normal IO state before continuing to probe. This allows us to give a more descriptive message
of what is wrong.

Without this change, the driver will attempt to probe up to our first
call of .reset_hw() which will be unable to read registers and act as if
a surprise remove event occurred.

Quoted 8 lines
Quoted 4 lines

---
?drivers/net/ethernet/intel/fm10k/fm10k_pci.c | 6 ++++++ ?1 file changed, 6 insertions(+)

This does not apply at all, the code was already removed in a previous
patch. ?So I am dropping this patch.

I'll take a look and re-submit a version on top of queue if we still need something.

Thanks,
Jake