netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <jdb@comx.dk>
To: "e1000-devel@lists.sourceforge.net"
	<e1000-devel@lists.sourceforge.net>,
	Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>,
	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@intel.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Benny Amorsen <benny+usenet@amorsen.dk>,
	"Skidmore, Donald C" <donald.c.skidmore@intel.com>,
	Ben Greear <greearb@candelatech.com>,
	"Fujinaka, Todd" <todd.fujinaka@intel.com>,
	David Lamparter <equinox@diac24.net>,
	Robert Bays <robert@herjulf.net>,
	"Ronciak, John" <john.ronciak@intel.com>
Subject: [PATCH RFC] ixgbe: Module param "allow_any_sfp" for allowing unsupported SFP+ modules
Date: Thu, 19 Jan 2012 15:46:45 +0100	[thread overview]
Message-ID: <1326984405.2795.91.camel@probook> (raw)
In-Reply-To: <1326925160.2795.45.camel@probook>


Intel are limiting which SFP's can use in their NICs, due to support issues.
This restriction comes from an EEPROM setting IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP.
This is for example the case with the 10Gbit/s X520-DA2 NIC.

Add a module param "allow_any_sfp", which can override the EEPROM
setting, and allows any unsupported SFP+ module to be used.  When
doing so, print disclaimer of unsupported usage.

Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c |   23 ++++++++++++++++++++---
 1 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c
index 7cf1e1f..2ccee6f 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c
@@ -32,6 +32,12 @@
 #include "ixgbe_common.h"
 #include "ixgbe_phy.h"
 
+#define ALLOW_ANY_SFP_DEFAULT 0
+static unsigned int allow_any_sfp __read_mostly = ALLOW_ANY_SFP_DEFAULT;
+module_param(allow_any_sfp, uint, 0644);
+MODULE_PARM_DESC(allow_any_sfp,
+		 "Allow any SFP+ module, even if EEPROM disallow it");
+
 static void ixgbe_i2c_start(struct ixgbe_hw *hw);
 static void ixgbe_i2c_stop(struct ixgbe_hw *hw);
 static s32 ixgbe_clock_in_i2c_byte(struct ixgbe_hw *hw, u8 *data);
@@ -844,6 +850,7 @@ s32 ixgbe_identify_sfp_module_generic(struct ixgbe_hw *hw)
 	u8 cable_tech = 0;
 	u8 cable_spec = 0;
 	u16 enforce_sfp = 0;
+	struct ixgbe_adapter *adapter = NULL;
 
 	if (hw->mac.ops.get_media_type(hw) != ixgbe_media_type_fiber) {
 		hw->phy.sfp_type = ixgbe_sfp_type_not_present;
@@ -1068,9 +1075,19 @@ s32 ixgbe_identify_sfp_module_generic(struct ixgbe_hw *hw)
 			if (hw->phy.type == ixgbe_phy_sfp_intel) {
 				status = 0;
 			} else {
-				hw_dbg(hw, "SFP+ module not supported\n");
-				hw->phy.type = ixgbe_phy_sfp_unsupported;
-				status = IXGBE_ERR_SFP_NOT_SUPPORTED;
+				adapter = hw->back; /* used by e_dev_err macro*/
+				e_dev_err(
+					"SFP+ module not supported by Intel\n");
+				if (allow_any_sfp) { /* modul param override */
+					e_dev_err(
+					"Continue WITHOUT support, SFP+ module "
+					"vendor OUI:0x%06X (enum phy.type:%d)\n",
+					vendor_oui >> 8, hw->phy.type);
+					status = 0;
+				} else {
+					hw->phy.type = ixgbe_phy_sfp_unsupported;
+					status = IXGBE_ERR_SFP_NOT_SUPPORTED;
+				}
 			}
 		} else {
 			status = 0;

  parent reply	other threads:[~2012-01-19 14:46 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-18 11:30 ixgbe: Unsupported SFP+ modules on 10Gbit/s X520-DA2 NIC? Jesper Dangaard Brouer
2012-01-18 17:13 ` Jesse Brandeburg
2012-01-18 20:00   ` Jesper Dangaard Brouer
2012-01-18 21:45   ` Benny Amorsen
2012-01-18 22:19     ` Jesper Dangaard Brouer
2012-01-18 22:43       ` Ben Greear
2012-01-19 14:46       ` Jesper Dangaard Brouer [this message]
2012-01-20  1:12         ` [PATCH RFC] ixgbe: Module param "allow_any_sfp" for allowing unsupported SFP+ modules Jeff Kirsher
2012-01-18 22:21     ` [E1000-devel] ixgbe: Unsupported SFP+ modules on 10Gbit/s X520-DA2 NIC? Fujinaka, Todd
2012-01-18 22:40       ` Ben Greear
2012-01-19 11:50         ` David Lamparter
2012-01-19  1:12       ` [E1000-devel] " Chuck Anderson
2012-01-19  2:55         ` Simon Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1326984405.2795.91.camel@probook \
    --to=jdb@comx.dk \
    --cc=benny+usenet@amorsen.dk \
    --cc=donald.c.skidmore@intel.com \
    --cc=e1000-devel@lists.sourceforge.net \
    --cc=equinox@diac24.net \
    --cc=greearb@candelatech.com \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=john.ronciak@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=peter.p.waskiewicz.jr@intel.com \
    --cc=robert@herjulf.net \
    --cc=todd.fujinaka@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).