From patchwork Wed Jan 18 22:19:20 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jesper Dangaard Brouer X-Patchwork-Id: 136700 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 8E50AB6EE8 for ; Thu, 19 Jan 2012 09:19:41 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753976Ab2ARWT0 (ORCPT ); Wed, 18 Jan 2012 17:19:26 -0500 Received: from lanfw001a.cxnet.dk ([87.72.215.196]:54671 "EHLO lanfw001a.cxnet.dk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753721Ab2ARWTW (ORCPT ); Wed, 18 Jan 2012 17:19:22 -0500 Received: from [87.72.44.26] (lanvpn001a.cxnet.dk [87.72.215.222]) by lanfw001a.cxnet.dk (Postfix) with ESMTP id A9E551635E6; Wed, 18 Jan 2012 23:19:20 +0100 (CET) Subject: Re: ixgbe: Unsupported SFP+ modules on 10Gbit/s X520-DA2 NIC? From: Jesper Dangaard Brouer To: Benny Amorsen Cc: Jesse Brandeburg , "e1000-devel@lists.sourceforge.net" , "Skidmore, Donald C" , "Waskiewicz Jr, Peter P" , "netdev@vger.kernel.org" , "Kirsher, Jeffrey T" In-Reply-To: References: <1326886258.19261.25.camel@probook> <20120118091351.000052fc@unknown> Organization: ComX Networks A/S Date: Wed, 18 Jan 2012 23:19:20 +0100 Message-ID: <1326925160.2795.45.camel@probook> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, 2012-01-18 at 22:45 +0100, Benny Amorsen wrote: > Jesse Brandeburg writes: > > > For X520 adapters, the documentation[1] states that which SFP+ > > adapters are/are not supported. Direct attach cables are also > > supported. > > > > [1] http://www.intel.com/support/network/adapter/pro100/sb/CS-030612.htm > > I can't believe that locked optics have now arrived on commodity > hardware. I have been trying to migrate to all-Intel networking at work; > that effort is certainly on hold now. I cannot understand why Intel are pulling a stunt like this! :-( I have read the code, and the limitation comes from a EEPROM setting on the NIC, see define "IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP 0x1". Here is a (untested) patch I believe removes the limitation in the driver: [PATCH] ixgbe: Always allow any SFP+ regardless of EEPROM setting. Intel are trying to limit which SFP's we can use in our NICs. We don't like this practices in the Linux Kernel. Signed-off-by: Jesper Dangaard Brouer --- drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c index 7cf1e1f..2b13083 100644 --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c @@ -1061,6 +1061,8 @@ s32 ixgbe_identify_sfp_module_generic(struct ixgbe_hw *hw) } hw->mac.ops.get_device_caps(hw, &enforce_sfp); + /* Hack: Always allow any SFP regardless of EEPROM setting */ + enforce_sfp |= IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP; if (!(enforce_sfp & IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP) && !((hw->phy.sfp_type == ixgbe_sfp_type_1g_cu_core0) || (hw->phy.sfp_type == ixgbe_sfp_type_1g_cu_core1))) {