From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: "Tantilov, Emil S" <emil.s.tantilov@intel.com>,
"Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>,
"davem@davemloft.net" <davem@davemloft.net>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"gospo@redhat.com" <gospo@redhat.com>,
"sassmann@redhat.com" <sassmann@redhat.com>
Subject: Re: [net-next 01/11] ixgbe: fix detection of SFP+ capable interfaces
Date: Wed, 14 May 2014 22:16:29 +0400 [thread overview]
Message-ID: <5373B2FD.5060505@cogentembedded.com> (raw)
In-Reply-To: <87618083B2453E4A8714035B62D679924FF672BE@FMSMSX105.amr.corp.intel.com>
Hello.
On 05/14/2014 08:59 PM, Tantilov, Emil S wrote:
>>> From: Emil Tantilov <emil.s.tantilov@intel.com>
>>> In cases where the driver is loaded while there are no SFP+ modules in
>>> the cage the interface was not being detected as SFP capable. To account
>>> for this the driver called identify_sfp in ixgbe_get_settings to make
>>> sure the data is correct. However when there is no SFP+ module in the cage
>>> the driver waits for the I2C reads to time out which can take more than a
>>> second and will cause issues with tools (like net-snmp) that may poll
>>> for that information.
>>> This patch resolves the issue by identifying 82599 based NIC with no PHY
>>> type set as SFP capable which allows the driver to detect the SFP module
>>> when the interface is brought up. As result of this we can also remove the
>>> identify_sfp call from ixgbe_get_settings.
>>> Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
>>> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
>>> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>> [...]
>>> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
>>> b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
>>> index 8089ea9..e44c42a 100644
>>> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
>>> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
>>> @@ -4660,6 +4660,10 @@ static inline bool ixgbe_is_sfp(struct ixgbe_hw *hw)
>>> case ixgbe_phy_nl:
>>> if (hw->mac.type == ixgbe_mac_82598EB)
>>> return true;
>>> + /* ixgbe_phy_none is set when no SFP module is present */
>>> + case ixgbe_phy_none:
>>> + if (hw->mac.type == ixgbe_mac_82599EB)
>>> + return true;
>> Shouldn't it just be combined with the previous case?
> How can you combine them? The previous case is for ixgbe_phy_nl and 82598 macs this patch is for ixgbe_phy_none and 82599.
Ah, sorry, I've misread 82598EB as 82599EB.
> Thanks,
> Emil
WBR, Sergei
next prev parent reply other threads:[~2014-05-14 18:16 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-14 8:54 [net-next 00/11][pull request] Intel Wired LAN Driver Updates Jeff Kirsher
2014-05-14 8:54 ` [net-next 01/11] ixgbe: fix detection of SFP+ capable interfaces Jeff Kirsher
2014-05-14 12:26 ` Sergei Shtylyov
2014-05-14 16:59 ` Tantilov, Emil S
2014-05-14 18:16 ` Sergei Shtylyov [this message]
2014-05-14 18:22 ` Tantilov, Emil S
2014-05-14 19:00 ` David Miller
2014-05-14 8:54 ` [net-next 02/11] ixgbe: clean up checkpatch warnings about CODE_INDENT and LEADING_SPACE Jeff Kirsher
2014-05-14 16:25 ` Joe Perches
2014-05-14 20:48 ` Keller, Jacob E
2014-05-14 8:54 ` [net-next 03/11] ixgbe: fix function-like macro, remove semicolon Jeff Kirsher
2014-05-14 8:54 ` [net-next 04/11] ixgbe: fix checkpatch style of blank line after declaration Jeff Kirsher
2014-05-14 8:54 ` [net-next 05/11] ixgbe: fix several concatenated strings to single line Jeff Kirsher
2014-05-14 8:54 ` [net-next 06/11] ixgbe: add braces around else block Jeff Kirsher
2014-05-14 8:54 ` [net-next 07/11] ixgbe: don't check NULL for debugfs_remove_recursive Jeff Kirsher
2014-05-14 8:54 ` [net-next 08/11] ixgbe: add space between operands to & Jeff Kirsher
2014-05-14 8:54 ` [net-next 09/11] ixgbe: add /* fallthrough */ comment to case statements Jeff Kirsher
2014-05-14 8:54 ` [net-next 10/11] igb/ixgbe: remove return statements for void functions Jeff Kirsher
2014-05-14 8:54 ` [net-next 11/11] i40e,igb,ixgbe: remove usless return statements Jeff Kirsher
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=5373B2FD.5060505@cogentembedded.com \
--to=sergei.shtylyov@cogentembedded.com \
--cc=davem@davemloft.net \
--cc=emil.s.tantilov@intel.com \
--cc=gospo@redhat.com \
--cc=jeffrey.t.kirsher@intel.com \
--cc=netdev@vger.kernel.org \
--cc=sassmann@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.