DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Wang, Haiyue" <haiyue.wang@intel.com>,
	<stephend@silicom-usa.com>, "Lu, Wenzhuo" <wenzhuo.lu@intel.com>,
	"Changchun Ouyang" <changchun.ouyang@intel.com>,
	"Zhang, Helin" <helin.zhang@intel.com>
Cc: <dev@dpdk.org>, "Wang, Wen" <wenw@silicom-usa.com>, <stable@dpdk.org>
Subject: RE: [PATCH v2 3/7] net/ixgbe: Check that SFF-8472 soft rate select is supported before write
Date: Tue, 21 Dec 2021 09:57:57 +0100	[thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D86D8B@smartserver.smartshare.dk> (raw)
In-Reply-To: <BYAPR11MB34957184FD7BED1AE8BD286FF77C9@BYAPR11MB3495.namprd11.prod.outlook.com>

> From: Wang, Haiyue [mailto:haiyue.wang@intel.com]
> Sent: Tuesday, 21 December 2021 02.15
> 
> > -----Original Message-----
> > From: Stephen Douthit <stephend@silicom-usa.com>
> > Sent: Tuesday, December 21, 2021 05:33
> >
> > On 12/20/21 02:53, Wang, Haiyue wrote:
> > >> -----Original Message-----
> > >> From: Stephen Douthit <stephend@silicom-usa.com>
> > >> Sent: Tuesday, December 7, 2021 06:19
> > >>
> > >> Make sure an SFP is really a SFF-8472 device that supports the
> optional
> > >> soft rate select feature before just blindly poking those I2C
> registers.
> > >>
> > >> Skip all I2C traffic if we know there's no SFP.
> > >>
> > >> Fixes: f3430431aba ("ixgbe/base: add SFP+ dual-speed support")
> > >> Cc: stable@dpdk.org
> > >>
> > >> Signed-off-by: Stephen Douthit <stephend@silicom-usa.com>
> > >> ---
> > >
> > >
> > >>        /* Set RS0 */
> > >>        status = hw->phy.ops.read_i2c_byte(hw,
> IXGBE_SFF_SFF_8472_OSCB,
> > >>
> IXGBE_I2C_EEPROM_DEV_ADDR2,
> > >> diff --git a/drivers/net/ixgbe/base/ixgbe_phy.h
> b/drivers/net/ixgbe/base/ixgbe_phy.h
> > >> index ceefbb3e68..cd57ce040f 100644
> > >> --- a/drivers/net/ixgbe/base/ixgbe_phy.h
> > >> +++ b/drivers/net/ixgbe/base/ixgbe_phy.h
> > >> @@ -21,6 +21,7 @@
> > >>   #define IXGBE_SFF_CABLE_TECHNOLOGY   0x8
> > >>   #define IXGBE_SFF_CABLE_SPEC_COMP    0x3C
> > >>   #define IXGBE_SFF_SFF_8472_SWAP              0x5C
> > >> +#define IXGBE_SFF_SFF_8472_EOPT              0x5D
> > >
> > > Looks like this is YOUR platform specific, then this patchset can't
> be
> > > merged. : - (
> >
> > This isn't anything unique to our hardware, these values are coming
> from
> > the SFF-8472 SFP+ I2C specification.
> >
> > The ability to do a soft rate select via I2C is an optional feature,
> and
> > modules that support it are supposed to set bit 3 in byte 93 (0x5d),
> the
> > "Enhanced Options" register, to advertise the functionality.
> >
> > Please see section 8.10 and Table 8-6 in the SFF-8472 spec.
> >
> > Checking the RATE_SELECT bit flag may be overkill since the
> transceiver
> > is supposed to ignore writes to rate select control bits if the
> feature
> > isn't implemented.  I can drop that check if you like, but the other
> > checks for a 8472 device (vs 8079) aren't anything different than
> what
> > already happens in the driver elsewhere[1].  I'd argue that testing
> that
> > a feature is supported in hardware before trying to use it is normal
> > driver behavior.
> >
> > If instead you mean that the entire series is somehow applicable only
> to
> > our hardware, I'm not sure why.
> >
> > That hotplug issue isn't seen on the same hardware when using the
> Linux
> > driver; so it's a dpdk problem (at least on C3000 ixgbe devs), and
> not a
> 
> I can't find your related fix in two official Linux drivers:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree
> /drivers/net/ethernet/intel/ixgbe
> https://www.intel.com/content/www/us/en/download/14302/14687/intel-
> network-adapter-driver-for-pcie-intel-10-gigabit-ethernet-network-
> connections-under-linux.html?
> 
> Normally, DPDK keeps sync with this kind of release.
> 

Working with the Linux kernel mainline drivers is good advice.

The official Intel Linux drivers seem to be ages behind the Kernel mainline, and they don't fully support the C3000 NICs, so don’t waste any time there! We recently tried using the official Intel Linux drivers for a C3338 based project (using Kernel 3.19 in 32 bit mode with x2APIC disabled), and they didn't work at all. We ended up backporting the necessary changes from the kernel mainline instead.

> > hardware problem.  Fixing the hotplug/rateswap issue was my primary
> > goal, the other patches fix problems I found along the way while
> > debugging.
> >
> > I can also reproduce the hotplug/rateswap issue on the PLCC-B, an
> Intel
> > reference design for the C3000 family, so again, not unique to this
> > platform.
> 
> I guess this is just in C3000 reference board SDK ?
> 
> I recommend you submit the fix to kernel firstly, you will get more
> experts' reviews and fully test:
> 
> https://patchwork.ozlabs.org/project/intel-wired-lan/list/
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
> 


  reply	other threads:[~2021-12-21  8:58 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-06 22:19 [PATCH v2 0/7] ixgbe SFP handling fixes Stephen Douthit
2021-12-06 22:19 ` [PATCH v2 1/7] net/ixgbe: Fix ixgbe_is_sfp() to return valid result for X550EM_a devs Stephen Douthit
2021-12-20  7:45   ` Wang, Haiyue
2021-12-20 21:32     ` Stephen Douthit
2021-12-06 22:19 ` [PATCH v2 2/7] net/ixgbe: Add ixgbe_check_sfp_cage() for testing state of PRSNT# signal Stephen Douthit
2021-12-06 22:19 ` [PATCH v2 3/7] net/ixgbe: Check that SFF-8472 soft rate select is supported before write Stephen Douthit
2021-12-20  7:53   ` Wang, Haiyue
2021-12-20 21:32     ` Stephen Douthit
2021-12-21  1:15       ` Wang, Haiyue
2021-12-21  8:57         ` Morten Brørup [this message]
2021-12-22  1:24           ` Wang, Haiyue
2021-12-22 10:43             ` Morten Brørup
2021-12-22 16:03               ` Wang, Haiyue
2021-12-22 19:13                 ` Morten Brørup
2021-12-22 21:44                 ` Stephen Douthit
2021-12-23  0:55                   ` Wang, Haiyue
2022-01-18 21:06                     ` Stephen Douthit
2022-01-19  0:31                       ` Wang, Haiyue
2022-02-07 16:04                         ` Ferruh Yigit
2022-02-08 13:50                           ` Jeff Daly
2022-02-08 14:52                             ` Ferruh Yigit
2022-02-09  4:00                               ` Wang, Haiyue
2022-02-09 13:33                                 ` Ferruh Yigit
2022-02-09 13:43                                   ` Wang, Haiyue
2021-12-21 14:05         ` Stephen Douthit
2021-12-06 22:19 ` [PATCH v2 4/7] net/ixgbe: Run 82599 link status workaround only on affected devices Stephen Douthit
2021-12-06 22:19 ` [PATCH v2 5/7] net/ixgbe: Fix SFP detection and linking on hotplug Stephen Douthit
2022-02-07 16:07   ` Ferruh Yigit
2021-12-06 22:19 ` [PATCH v2 6/7] net/ixgbe: Retry SFP ID read field to handle misbehaving SFPs Stephen Douthit
2021-12-06 22:19 ` [PATCH v2 7/7] net/ixgbe: Treat 1G Cu SFPs as 1G SX on the X550 devices Stephen Douthit
2021-12-17  9:29 ` [PATCH v2 0/7] ixgbe SFP handling fixes Thomas Monjalon
2022-02-24 15:23 ` [PATCH v3 0/3] " Jeff Daly
2022-02-24 15:23   ` [PATCH v3 1/3] net/ixgbe: Fix ixgbe_is_sfp() to return valid result for X550EM_a devs Jeff Daly
2022-02-24 15:23   ` [PATCH v3 2/3] net/ixgbe: Limit SDP3 check of TX_DISABLE to appropriate devices Jeff Daly
2022-02-24 15:23   ` [PATCH v3 3/3] net/ixgbe: Fix SFP detection and linking on hotplug Jeff Daly
2022-02-25  1:56     ` Wang, Haiyue
2022-02-25 20:50 ` [PATCH v4 " Jeff Daly
2022-02-26 15:57   ` Ferruh Yigit
2022-02-28 15:29 ` [PATCH v4 0/3] ixgbe SFP handling fixes Jeff Daly
2022-02-28 15:29   ` [PATCH v4 1/3] net/ixgbe: Fix ixgbe_is_sfp() to return valid result for X550EM_a devs Jeff Daly
2022-03-01  5:56     ` Wang, Haiyue
2022-03-01 11:18       ` Zhang, Qi Z
2022-03-06 17:56         ` Thomas Monjalon
2022-03-08 15:01           ` Jeff Daly
2022-02-28 15:29   ` [PATCH v4 2/3] net/ixgbe: Limit SDP3 check of TX_DISABLE to appropriate devices Jeff Daly
2022-02-28 15:29   ` [PATCH v4 3/3] net/ixgbe: Fix SFP detection and linking on hotplug Jeff Daly
2022-03-12 13:03     ` Jeff Daly
2022-03-10 12:35   ` [PATCH v4 0/3] ixgbe SFP handling fixes Zhang, Qi Z
2022-04-12 17:34   ` [PATCH v5 0/2] " Jeff Daly
2022-04-12 17:34     ` [PATCH v5 1/2] net/ixgbe: Limit SDP3 check of TX_DISABLE to appropriate devices Jeff Daly
2022-04-12 17:34     ` [PATCH v5 2/2] net/ixgbe: Fix SFP detection and linking on hotplug Jeff Daly
2022-04-12 17:42   ` [PATCH v6 0/2] ixgbe SFP handling fixes Jeff Daly
2022-04-12 17:42     ` [PATCH v6 1/2] net/ixgbe: Limit SDP3 check of TX_DISABLE to appropriate devices Jeff Daly
2022-04-13  1:21       ` Wang, Haiyue
2022-04-13 15:32         ` Jeff Daly
2022-04-14  1:56           ` Wang, Haiyue
2022-04-12 17:42     ` [PATCH v6 2/2] net/ixgbe: Fix SFP detection and linking on hotplug Jeff Daly
2022-04-13  2:46       ` Wang, Haiyue
2022-04-13  6:57         ` Morten Brørup
2022-04-13  7:01           ` Wang, Haiyue
2022-04-13  7:19             ` Morten Brørup
2022-04-13 11:49               ` Wang, Haiyue
2022-04-13 12:54                 ` Morten Brørup
2022-04-13 15:23               ` Jeff Daly
2022-04-14 10:49         ` Jeff Daly
2022-04-14 11:08           ` Jeff Daly
2022-04-14  2:49       ` Wang, Haiyue
2022-04-14  2:59         ` Wang, Haiyue
2022-04-14 10:40           ` Jeff Daly
2022-04-14 12:11             ` Wang, Haiyue
2022-04-18 21:54               ` Jeff Daly
2022-04-19  2:05                 ` Wang, Haiyue
2022-04-19 17:33                   ` Jeff Daly
2022-04-20  1:09                     ` Wang, Haiyue
2022-04-21 17:31                       ` Jeff Daly
2022-04-22  2:11                         ` Wang, Haiyue
2022-05-12  1:26       ` Zhang, Qi Z
2022-05-25 16:55         ` Jeff Daly

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=98CBD80474FA8B44BF855DF32C47DC35D86D8B@smartserver.smartshare.dk \
    --to=mb@smartsharesystems.com \
    --cc=changchun.ouyang@intel.com \
    --cc=dev@dpdk.org \
    --cc=haiyue.wang@intel.com \
    --cc=helin.zhang@intel.com \
    --cc=stable@dpdk.org \
    --cc=stephend@silicom-usa.com \
    --cc=wenw@silicom-usa.com \
    --cc=wenzhuo.lu@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).