[net-2.6 PATCH 1/4] ixgbe: fix issues with failing to detect insert of unsupported module

[net-2.6 PATCH 1/4] ixgbe: fix issues with failing to detect insert of unsupported module

[Jeff Kirsher]

From: Don Skidmore <donald.c.skidmore@intel.com>

Several small fixes around negative test case of the insertion of a
IXGBE_ERR_NOT_SUPPORTED module.

- mdio45_probe call was always failing due to mdio.prtad not being
set.  The function set to mdio.mdio_read was still working as we just
happen to always be at prtad == 0.  This will allow us to set the phy_id
and phy.type correctly now.

- There was timing issue with i2c calls when initiated from a tasklet.
A small delay was added to allow the electrical oscillation to calm down.

- Logic change in ixgbe_sfp_task that allows NOT_SUPPORTED condition
to be recognized.

Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---

 drivers/net/ixgbe/ixgbe_main.c |    8 ++++++--
 drivers/net/ixgbe/ixgbe_phy.c  |    3 +++
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index 5588ef4..aaf482c 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -3724,7 +3724,7 @@ static void ixgbe_sfp_task(struct work_struct *work)
 	if ((hw->phy.type == ixgbe_phy_nl) &&
 	    (hw->phy.sfp_type == ixgbe_sfp_type_not_present)) {
 		s32 ret = hw->phy.ops.identify_sfp(hw);
-		if (ret)
+		if (ret == IXGBE_ERR_SFP_NOT_PRESENT)
 			goto reschedule;
 		ret = hw->phy.ops.reset(hw);
 		if (ret == IXGBE_ERR_SFP_NOT_SUPPORTED) {
@@ -4534,13 +4534,17 @@ static void ixgbe_sfp_config_module_task(struct work_struct *work)
 	u32 err;
 
 	adapter->flags |= IXGBE_FLAG_IN_SFP_MOD_TASK;
+
+	/* Time for electrical oscillations to settle down */
+	msleep(100);
 	err = hw->phy.ops.identify_sfp(hw);
+
 	if (err == IXGBE_ERR_SFP_NOT_SUPPORTED) {
 		dev_err(&adapter->pdev->dev, "failed to initialize because "
 			"an unsupported SFP+ module type was detected.\n"
 			"Reload the driver after installing a supported "
 			"module.\n");
-		ixgbe_down(adapter);
+		unregister_netdev(adapter->netdev);
 		return;
 	}
 	hw->mac.ops.setup_sfp(hw);
diff --git a/drivers/net/ixgbe/ixgbe_phy.c b/drivers/net/ixgbe/ixgbe_phy.c
index 453e966..9ecad17 100644
--- a/drivers/net/ixgbe/ixgbe_phy.c
+++ b/drivers/net/ixgbe/ixgbe_phy.c
@@ -60,6 +60,7 @@ s32 ixgbe_identify_phy_generic(struct ixgbe_hw *hw)
 
 	if (hw->phy.type == ixgbe_phy_unknown) {
 		for (phy_addr = 0; phy_addr < IXGBE_MAX_PHY_ADDR; phy_addr++) {
+			hw->phy.mdio.prtad = phy_addr;
 			if (mdio45_probe(&hw->phy.mdio, phy_addr) == 0) {
 				ixgbe_get_phy_id(hw);
 				hw->phy.type =
@@ -68,6 +69,8 @@ s32 ixgbe_identify_phy_generic(struct ixgbe_hw *hw)
 				break;
 			}
 		}
+		/* clear value if nothing found */
+		hw->phy.mdio.prtad = 0;
 	} else {
 		status = 0;
 	}

[net-2.6 PATCH 2/4] ixgbe: fix regression on some 82598 adapters

[Jeff Kirsher]

From: Don Skidmore <donald.c.skidmore@intel.com>

The change to check the SFP+ module again on open() was
causing the XFP (non-SFP+) adapters to be rejected. We
only want to try and re-identify the SFP+ module if the
original probe found that this device was an SFP+ device.
So for this code path (driver loaded with SFP module, module
inserted, ifconfig up of the device) the type will be
ixgbe_phy_unknown for an unidentified SFP+ module.  So we
only check if that is the case.

This problem also shows up on Copper devices.

Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---

 drivers/net/ixgbe/ixgbe_main.c |   24 ++++++++++++++----------
 1 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index aaf482c..cf39f5a 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -2697,19 +2697,23 @@ static int ixgbe_up_complete(struct ixgbe_adapter *adapter)
 
 	/*
 	 * For hot-pluggable SFP+ devices, a new SFP+ module may have
-	 * arrived before interrupts were enabled.  We need to kick off
-	 * the SFP+ module setup first, then try to bring up link.
+	 * arrived before interrupts were enabled but after probe.  Such
+	 * devices wouldn't have their type identified yet. We need to
+	 * kick off the SFP+ module setup first, then try to bring up link.
 	 * If we're not hot-pluggable SFP+, we just need to configure link
 	 * and bring it up.
 	 */
-	err = hw->phy.ops.identify(hw);
-	if (err == IXGBE_ERR_SFP_NOT_SUPPORTED) {
-		dev_err(&adapter->pdev->dev, "failed to initialize because "
-			"an unsupported SFP+ module type was detected.\n"
-			"Reload the driver after installing a supported "
-			"module.\n");
-		ixgbe_down(adapter);
-		return err;
+	if (hw->phy.type == ixgbe_phy_unknown) {
+		err = hw->phy.ops.identify(hw);
+		if (err == IXGBE_ERR_SFP_NOT_SUPPORTED) {
+			dev_err(&adapter->pdev->dev, "failed to initialize "
+				"because an unsupported SFP+ module type "
+				"was detected.\n"
+				"Reload the driver after installing a "
+				"supported module.\n");
+			ixgbe_down(adapter);
+			return err;
+		}
 	}
 
 	if (ixgbe_is_sfp(hw)) {

[net-2.6 PATCH 3/4] ixgbe: fix inconsistent SFP/SFP+ failure results.

[Jeff Kirsher]

From: Don Skidmore <donald.c.skidmore@intel.com>

Currently if we loaded the driver, insert an unsupported module, and then
attempt to "ifconfig up" the device it will be brought down but the netdev
would not be unregistered. This behavior is different than all other
code paths. This patch corrects that by down'ing the device and then
scheduling the sfp_config_module_task tasklet. The tasklet will detect
this condition (like it does with other code paths) and do the
unregister_netdev().

I also removed the log message as this condition (an unsupported SFP+
module) will be logged in sfp_config_module_task.

Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---

 drivers/net/ixgbe/ixgbe_main.c |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index cf39f5a..a3061aa 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -2706,12 +2706,12 @@ static int ixgbe_up_complete(struct ixgbe_adapter *adapter)
 	if (hw->phy.type == ixgbe_phy_unknown) {
 		err = hw->phy.ops.identify(hw);
 		if (err == IXGBE_ERR_SFP_NOT_SUPPORTED) {
-			dev_err(&adapter->pdev->dev, "failed to initialize "
-				"because an unsupported SFP+ module type "
-				"was detected.\n"
-				"Reload the driver after installing a "
-				"supported module.\n");
+			/*
+			 * Take the device down and schedule the sfp tasklet
+			 * which will unregister_netdev and log it.
+			 */
 			ixgbe_down(adapter);
+			schedule_work(&adapter->sfp_config_module_task);
 			return err;
 		}
 	}

[net-2.6 PATCH 4/4] ixgbe: Not allow 8259x unsupported wol options change from ethtool

[Jeff Kirsher]

From: Mallikarjuna R Chilakala <mallikarjuna.chilakala@intel.com>

Wake-on-lan is currently only supported by 82599 KX4 devices, in all
other cases return a proper value from ixgbe_wol_exclusion function call.
Otherwise from ethtool we will be able to change wol options of
unsupported 8259x devices.

Signed-off-by: Mallikarjuna R Chilakala <mallikarjuna.chilakala@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---

 drivers/net/ixgbe/ixgbe_ethtool.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_ethtool.c b/drivers/net/ixgbe/ixgbe_ethtool.c
index 0f7b6a3..2a97800 100644
--- a/drivers/net/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ixgbe/ixgbe_ethtool.c
@@ -1830,7 +1830,6 @@ static int ixgbe_wol_exclusion(struct ixgbe_adapter *adapter,
 		break;
 	default:
 		wol->supported = 0;
-		retval = 0;
 	}
 
 	return retval;

Re: [net-2.6 PATCH 1/4] ixgbe: fix issues with failing to detect insert of unsupported module

[David Miller]

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 02 Jul 2009 15:50:12 -0700

> From: Don Skidmore <donald.c.skidmore@intel.com>
> 
> Several small fixes around negative test case of the insertion of a
> IXGBE_ERR_NOT_SUPPORTED module.
> 
> - mdio45_probe call was always failing due to mdio.prtad not being
> set.  The function set to mdio.mdio_read was still working as we just
> happen to always be at prtad == 0.  This will allow us to set the phy_id
> and phy.type correctly now.
> 
> - There was timing issue with i2c calls when initiated from a tasklet.
> A small delay was added to allow the electrical oscillation to calm down.
> 
> - Logic change in ixgbe_sfp_task that allows NOT_SUPPORTED condition
> to be recognized.
> 
> Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

Applied.

Re: [net-2.6 PATCH 2/4] ixgbe: fix regression on some 82598 adapters

[David Miller]

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 02 Jul 2009 15:50:31 -0700

> From: Don Skidmore <donald.c.skidmore@intel.com>
> 
> The change to check the SFP+ module again on open() was
> causing the XFP (non-SFP+) adapters to be rejected. We
> only want to try and re-identify the SFP+ module if the
> original probe found that this device was an SFP+ device.
> So for this code path (driver loaded with SFP module, module
> inserted, ifconfig up of the device) the type will be
> ixgbe_phy_unknown for an unidentified SFP+ module.  So we
> only check if that is the case.
> 
> This problem also shows up on Copper devices.
> 
> Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

Applied.

Re: [net-2.6 PATCH 3/4] ixgbe: fix inconsistent SFP/SFP+ failure results.

[David Miller]

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 02 Jul 2009 15:50:52 -0700

> From: Don Skidmore <donald.c.skidmore@intel.com>
> 
> Currently if we loaded the driver, insert an unsupported module, and then
> attempt to "ifconfig up" the device it will be brought down but the netdev
> would not be unregistered. This behavior is different than all other
> code paths. This patch corrects that by down'ing the device and then
> scheduling the sfp_config_module_task tasklet. The tasklet will detect
> this condition (like it does with other code paths) and do the
> unregister_netdev().
> 
> I also removed the log message as this condition (an unsupported SFP+
> module) will be logged in sfp_config_module_task.
> 
> Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

Applied.

Re: [net-2.6 PATCH 4/4] ixgbe: Not allow 8259x unsupported wol options change from ethtool

[David Miller]

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 02 Jul 2009 15:51:10 -0700

> From: Mallikarjuna R Chilakala <mallikarjuna.chilakala@intel.com>
> 
> Wake-on-lan is currently only supported by 82599 KX4 devices, in all
> other cases return a proper value from ixgbe_wol_exclusion function call.
> Otherwise from ethtool we will be able to change wol options of
> unsupported 8259x devices.
> 
> Signed-off-by: Mallikarjuna R Chilakala <mallikarjuna.chilakala@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---

Applied.