[PATCH] ixgbe/base: Manual AN-37 for troublesome link partners for X550 SFI

[PATCH] ixgbe/base: Manual AN-37 for troublesome link partners for X550 SFI

[Jeff Daly]

Some SFP link partners exhibit a disinclination to autonegotiate
with X550 configured in SFI mode.  This patch enables a manual AN-37
restart to work around the problem.

Signed-off-by: Jeff Daly <jeffd@silicom-usa.com>
---
 drivers/net/ixgbe/base/ixgbe_type.h |  1 +
 drivers/net/ixgbe/base/ixgbe_x550.c | 51 +++++++++++++++++++++++++++++
 2 files changed, 52 insertions(+)

diff --git a/drivers/net/ixgbe/base/ixgbe_type.h b/drivers/net/ixgbe/base/ixgbe_type.h
index b7eec45635..9278b1e64c 100644
--- a/drivers/net/ixgbe/base/ixgbe_type.h
+++ b/drivers/net/ixgbe/base/ixgbe_type.h
@@ -4260,6 +4260,7 @@ struct ixgbe_hw {
 #define IXGBE_KRM_PMD_FLX_MASK_ST20(P)	((P) ? 0x9054 : 0x5054)
 #define IXGBE_KRM_TX_COEFF_CTRL_1(P)	((P) ? 0x9520 : 0x5520)
 #define IXGBE_KRM_RX_ANA_CTL(P)		((P) ? 0x9A00 : 0x5A00)
+#define IXGBE_KRM_FLX_TMRS_CTRL_ST31(P)	((P) ? 0x9180 : 0x5180)
 
 #define IXGBE_KRM_PMD_FLX_MASK_ST20_SFI_10G_DA		~(0x3 << 20)
 #define IXGBE_KRM_PMD_FLX_MASK_ST20_SFI_10G_SR		(1u << 20)
diff --git a/drivers/net/ixgbe/base/ixgbe_x550.c b/drivers/net/ixgbe/base/ixgbe_x550.c
index 8810d1658e..649d834715 100644
--- a/drivers/net/ixgbe/base/ixgbe_x550.c
+++ b/drivers/net/ixgbe/base/ixgbe_x550.c
@@ -2676,6 +2676,57 @@ STATIC s32 ixgbe_setup_sfi_x550a(struct ixgbe_hw *hw, ixgbe_link_speed *speed)
 				IXGBE_KRM_PMD_FLX_MASK_ST20(hw->bus.lan_id),
 				IXGBE_SB_IOSF_TARGET_KR_PHY, reg_val);
 
+	/* change mode enforcement rules to hybrid */
+	status = mac->ops.read_iosf_sb_reg(hw,
+				IXGBE_KRM_FLX_TMRS_CTRL_ST31(hw->bus.lan_id),
+				IXGBE_SB_IOSF_TARGET_KR_PHY, &reg_val);
+	status |= 0x0400;
+
+	status = mac->ops.write_iosf_sb_reg(hw,
+				IXGBE_KRM_FLX_TMRS_CTRL_ST31(hw->bus.lan_id),
+				IXGBE_SB_IOSF_TARGET_KR_PHY, reg_val);
+				
+	/* manually control the config */
+	status = mac->ops.read_iosf_sb_reg(hw,
+				IXGBE_KRM_LINK_CTRL_1(hw->bus.lan_id),
+				IXGBE_SB_IOSF_TARGET_KR_PHY, &reg_val);
+	status |= 0x20002240;
+
+	status = mac->ops.write_iosf_sb_reg(hw,
+				IXGBE_KRM_LINK_CTRL_1(hw->bus.lan_id),
+				IXGBE_SB_IOSF_TARGET_KR_PHY, reg_val);
+
+	/* move the AN base page values */
+	status = mac->ops.read_iosf_sb_reg(hw,
+				IXGBE_KRM_PCS_KX_AN(hw->bus.lan_id),
+				IXGBE_SB_IOSF_TARGET_KR_PHY, &reg_val);
+	status |= 0x1;
+
+	status = mac->ops.write_iosf_sb_reg(hw,
+				IXGBE_KRM_PCS_KX_AN(hw->bus.lan_id),
+				IXGBE_SB_IOSF_TARGET_KR_PHY, reg_val);
+
+	/* set the AN37 over CB mode */
+	status = mac->ops.read_iosf_sb_reg(hw,
+				IXGBE_KRM_AN_CNTL_4(hw->bus.lan_id),
+				IXGBE_SB_IOSF_TARGET_KR_PHY, &reg_val);
+	status |= 0x20000000;
+
+	status = mac->ops.write_iosf_sb_reg(hw,
+				IXGBE_KRM_AN_CNTL_4(hw->bus.lan_id),
+				IXGBE_SB_IOSF_TARGET_KR_PHY, reg_val);
+
+	/* restart AN manually */
+	status = mac->ops.read_iosf_sb_reg(hw,
+				IXGBE_KRM_LINK_CTRL_1(hw->bus.lan_id),
+				IXGBE_SB_IOSF_TARGET_KR_PHY, &reg_val);
+	status |= IXGBE_KRM_LINK_CTRL_1_TETH_AN_RESTART;
+
+	status = mac->ops.write_iosf_sb_reg(hw,
+				IXGBE_KRM_LINK_CTRL_1(hw->bus.lan_id),
+				IXGBE_SB_IOSF_TARGET_KR_PHY, reg_val);
+
+
 	/* Toggle port SW reset by AN reset. */
 	status = ixgbe_restart_an_internal_phy_x550em(hw);
 
-- 
2.25.1

[PATCH v2] ixgbe/base: Manual AN-37 for troublesome link partners for X550 SFI

[Jeff Daly]

Some SFP link partners exhibit a disinclination to autonegotiate
with X550 configured in SFI mode.  This patch enables a manual AN-37
restart to work around the problem.

--
v2 fixed whitespace

Signed-off-by: Jeff Daly <jeffd@silicom-usa.com>
---
 drivers/net/ixgbe/base/ixgbe_type.h |  1 +
 drivers/net/ixgbe/base/ixgbe_x550.c | 50 +++++++++++++++++++++++++++++
 2 files changed, 51 insertions(+)

diff --git a/drivers/net/ixgbe/base/ixgbe_type.h b/drivers/net/ixgbe/base/ixgbe_type.h
index b7eec45635..9278b1e64c 100644
--- a/drivers/net/ixgbe/base/ixgbe_type.h
+++ b/drivers/net/ixgbe/base/ixgbe_type.h
@@ -4260,6 +4260,7 @@ struct ixgbe_hw {
 #define IXGBE_KRM_PMD_FLX_MASK_ST20(P)	((P) ? 0x9054 : 0x5054)
 #define IXGBE_KRM_TX_COEFF_CTRL_1(P)	((P) ? 0x9520 : 0x5520)
 #define IXGBE_KRM_RX_ANA_CTL(P)		((P) ? 0x9A00 : 0x5A00)
+#define IXGBE_KRM_FLX_TMRS_CTRL_ST31(P)	((P) ? 0x9180 : 0x5180)
 
 #define IXGBE_KRM_PMD_FLX_MASK_ST20_SFI_10G_DA		~(0x3 << 20)
 #define IXGBE_KRM_PMD_FLX_MASK_ST20_SFI_10G_SR		(1u << 20)
diff --git a/drivers/net/ixgbe/base/ixgbe_x550.c b/drivers/net/ixgbe/base/ixgbe_x550.c
index 8810d1658e..a88546f98f 100644
--- a/drivers/net/ixgbe/base/ixgbe_x550.c
+++ b/drivers/net/ixgbe/base/ixgbe_x550.c
@@ -2676,6 +2676,56 @@ STATIC s32 ixgbe_setup_sfi_x550a(struct ixgbe_hw *hw, ixgbe_link_speed *speed)
 				IXGBE_KRM_PMD_FLX_MASK_ST20(hw->bus.lan_id),
 				IXGBE_SB_IOSF_TARGET_KR_PHY, reg_val);
 
+	/* change mode enforcement rules to hybrid */
+	status = mac->ops.read_iosf_sb_reg(hw,
+				IXGBE_KRM_FLX_TMRS_CTRL_ST31(hw->bus.lan_id),
+				IXGBE_SB_IOSF_TARGET_KR_PHY, &reg_val);
+	status |= 0x0400;
+
+	status = mac->ops.write_iosf_sb_reg(hw,
+				IXGBE_KRM_FLX_TMRS_CTRL_ST31(hw->bus.lan_id),
+				IXGBE_SB_IOSF_TARGET_KR_PHY, reg_val);
+
+	/* manually control the config */
+	status = mac->ops.read_iosf_sb_reg(hw,
+				IXGBE_KRM_LINK_CTRL_1(hw->bus.lan_id),
+				IXGBE_SB_IOSF_TARGET_KR_PHY, &reg_val);
+	status |= 0x20002240;
+
+	status = mac->ops.write_iosf_sb_reg(hw,
+				IXGBE_KRM_LINK_CTRL_1(hw->bus.lan_id),
+				IXGBE_SB_IOSF_TARGET_KR_PHY, reg_val);
+
+	/* move the AN base page values */
+	status = mac->ops.read_iosf_sb_reg(hw,
+				IXGBE_KRM_PCS_KX_AN(hw->bus.lan_id),
+				IXGBE_SB_IOSF_TARGET_KR_PHY, &reg_val);
+	status |= 0x1;
+
+	status = mac->ops.write_iosf_sb_reg(hw,
+				IXGBE_KRM_PCS_KX_AN(hw->bus.lan_id),
+				IXGBE_SB_IOSF_TARGET_KR_PHY, reg_val);
+
+	/* set the AN37 over CB mode */
+	status = mac->ops.read_iosf_sb_reg(hw,
+				IXGBE_KRM_AN_CNTL_4(hw->bus.lan_id),
+				IXGBE_SB_IOSF_TARGET_KR_PHY, &reg_val);
+	status |= 0x20000000;
+
+	status = mac->ops.write_iosf_sb_reg(hw,
+				IXGBE_KRM_AN_CNTL_4(hw->bus.lan_id),
+				IXGBE_SB_IOSF_TARGET_KR_PHY, reg_val);
+
+	/* restart AN manually */
+	status = mac->ops.read_iosf_sb_reg(hw,
+				IXGBE_KRM_LINK_CTRL_1(hw->bus.lan_id),
+				IXGBE_SB_IOSF_TARGET_KR_PHY, &reg_val);
+	status |= IXGBE_KRM_LINK_CTRL_1_TETH_AN_RESTART;
+
+	status = mac->ops.write_iosf_sb_reg(hw,
+				IXGBE_KRM_LINK_CTRL_1(hw->bus.lan_id),
+				IXGBE_SB_IOSF_TARGET_KR_PHY, reg_val);
+
 	/* Toggle port SW reset by AN reset. */
 	status = ixgbe_restart_an_internal_phy_x550em(hw);
 
-- 
2.25.1

RE: [PATCH v2] ixgbe/base: Manual AN-37 for troublesome link partners for X550 SFI

[Zhang, Qi Z]

Jeff:

> -----Original Message-----
> From: Jeff Daly <jeffd@silicom-usa.com>
> Sent: Thursday, March 17, 2022 2:59 AM
> To: dev@dpdk.org
> Cc: Wang, Haiyue <haiyue.wang@intel.com>
> Subject: [PATCH v2] ixgbe/base: Manual AN-37 for troublesome link partners
> for X550 SFI
> 
> Some SFP link partners exhibit a disinclination to autonegotiate with X550
> configured in SFI mode.  This patch enables a manual AN-37 restart to work
> around the problem.

This fix for some specific hardware in base code, unfortunately  Intel DPDK team don't have the device and the knowledge to approve this, the base code is delivered by our kernel software team, I will suggest you can send this to the kernel community to get the right expert to review.

Thanks
Qi

Re: [PATCH v2] ixgbe/base: Manual AN-37 for troublesome link partners for X550 SFI

[Thomas Monjalon]

18/05/2022 02:03, Zhang, Qi Z:
> From: Jeff Daly <jeffd@silicom-usa.com>
> > 
> > Some SFP link partners exhibit a disinclination to autonegotiate with X550
> > configured in SFI mode.  This patch enables a manual AN-37 restart to work
> > around the problem.
> 
> This fix for some specific hardware in base code,
> unfortunately  Intel DPDK team don't have the device
> and the knowledge to approve this,

That's why the work is collaborative.
You should get and trust knowledge from partners.
The only concerns of a maintainer should be:
	- good feature design
	- good code quality
	- no regression in known cases

> the base code is delivered by our kernel software team,
> I will suggest you can send this to the kernel community
> to get the right expert to review.

Which kind of expert do you imagine to review?
Intel team or Silicom people who are pushing these improvements?

There is another problem with asking Linux kernel change first:
the patch will land in GPL code, bringing difficulties to move
in BSD-licensed base code.

I suggest we make this process more flexible:
	1/ a contributor sends a patch for DPDK base code
	   with an explicit grant for backporting in any license.
	2/ Intel checks that there is no DPDK regression
	3/ patch is merged in DPDK
	4/ Intel merges it in the internal base code
	5/ Linux kernel team can backport the fix to Linux
	6/ Any other OS can backport the fix in its driver

Let's make the DPDK process open for everybody.

RE: [PATCH v2] ixgbe/base: Manual AN-37 for troublesome link partners for X550 SFI

[Zhang, Qi Z]

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Tuesday, May 24, 2022 6:43 PM
> To: Zhang, Qi Z <qi.z.zhang@intel.com>
> Cc: Daly, Jeff <jeffd@silicom-usa.com>; dev@dpdk.org; Wang, Haiyue
> <haiyue.wang@intel.com>; ferruh.yigit@amd.com;
> andrew.rybchenko@oktetlabs.ru; Richardson, Bruce
> <bruce.richardson@intel.com>
> Subject: Re: [PATCH v2] ixgbe/base: Manual AN-37 for troublesome link
> partners for X550 SFI
> 
> 18/05/2022 02:03, Zhang, Qi Z:
> > From: Jeff Daly <jeffd@silicom-usa.com>
> > >
> > > Some SFP link partners exhibit a disinclination to autonegotiate
> > > with X550 configured in SFI mode.  This patch enables a manual AN-37
> > > restart to work around the problem.
> >
> > This fix for some specific hardware in base code, unfortunately  Intel
> > DPDK team don't have the device and the knowledge to approve this,
> 
> That's why the work is collaborative.
> You should get and trust knowledge from partners.
> The only concerns of a maintainer should be:
> 	- good feature design
> 	- good code quality

These are the questions we can't answer, we don't understand the design,  what is " change mode enforcement rules to hybrid " means,  what is manual AN-37 here and what those numbers in the patch means.
Of cause we trust knowledge from our partners, but anyway this is an Intel product, only Intel have the right to authenticate this. unfortunately none of the active ixgbe DPDK maintainers and I have the knowledge
Meanwhile if this is an issue on DPDK, it could also be an issue on kernel driver that's why we suggest to submit to Linux community first where will be right people to answer above questions.

> 	- no regression in known cases
> 

> > the base code is delivered by our kernel software team, I will suggest
> > you can send this to the kernel community to get the right expert to
> > review.
> 
> Which kind of expert do you imagine to review?
> Intel team or Silicom people who are pushing these improvements?

> 
> There is another problem with asking Linux kernel change first:
> the patch will land in GPL code, bringing difficulties to move in BSD-licensed
> base code.

Only if the author agree to share the copy right to Intel, so Intel is able to re-license it to BSD as same as other base code.

> 
> I suggest we make this process more flexible:
> 	1/ a contributor sends a patch for DPDK base code
> 	   with an explicit grant for backporting in any license.
> 	2/ Intel checks that there is no DPDK regression
> 	3/ patch is merged in DPDK
> 	4/ Intel merges it in the internal base code
> 	5/ Linux kernel team can backport the fix to Linux
> 	6/ Any other OS can backport the fix in its driver

Right now, our base code in kernel is GPL license only,  code with BSD-3-clause can't be distrusted without change our license strategy, 
so it's the same effort if someone want to backport DPDK changes to kernel ( shared the copy right to Intel)

but I like your suggestion (if I understand correctly), have a dual licenses in kernel base code make things smoothly to backport from DPDK to kernel, I will feedback this.

> 
> Let's make the DPDK process open for everybody.

For sure, we should.

> 

Re: [PATCH v2] ixgbe/base: Manual AN-37 for troublesome link partners for X550 SFI

[Thomas Monjalon]

24/05/2022 15:42, Zhang, Qi Z:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 18/05/2022 02:03, Zhang, Qi Z:
> > > From: Jeff Daly <jeffd@silicom-usa.com>
> > > >
> > > > Some SFP link partners exhibit a disinclination to autonegotiate
> > > > with X550 configured in SFI mode.  This patch enables a manual AN-37
> > > > restart to work around the problem.
> > >
> > > This fix for some specific hardware in base code, unfortunately  Intel
> > > DPDK team don't have the device and the knowledge to approve this,
> > 
> > That's why the work is collaborative.
> > You should get and trust knowledge from partners.
> > The only concerns of a maintainer should be:
> > 	- good feature design
> > 	- good code quality
> 
> These are the questions we can't answer,
> we don't understand the design,
> what is " change mode enforcement rules to hybrid " means,
> what is manual AN-37 here and what those numbers in the patch means.

So these are the basic questions you should ask to be made clear
in the patch. That's the same for everybody: we must understand
the reason and the intent of any change.

> Of cause we trust knowledge from our partners,
> but anyway this is an Intel product,

The DPDK driver is not an Intel product.
This a community effort where anyone should be able to participate.

> only Intel have the right to authenticate this.

What do you mean by "authenticate"?

> unfortunately none of the active ixgbe DPDK maintainers and I have the knowledge
> Meanwhile if this is an issue on DPDK,
> it could also be an issue on kernel driver
> that's why we suggest to submit to Linux community first
> where will be right people to answer above questions.

Why Linux community is more able to review than DPDK,
or FreeBSD, or Windows, or any other community?

> > 	- no regression in known cases
> 
> > > the base code is delivered by our kernel software team, I will suggest
> > > you can send this to the kernel community to get the right expert to
> > > review.
> > 
> > Which kind of expert do you imagine to review?
> > Intel team or Silicom people who are pushing these improvements?
> 
> > There is another problem with asking Linux kernel change first:
> > the patch will land in GPL code, bringing difficulties to move in BSD-licensed
> > base code.
> 
> Only if the author agree to share the copy right to Intel,
> so Intel is able to re-license it to BSD as same as other base code.

Yes we should be able to grant such copyright in the commit message.

> > I suggest we make this process more flexible:
> > 	1/ a contributor sends a patch for DPDK base code
> > 	   with an explicit grant for backporting in any license.
> > 	2/ Intel checks that there is no DPDK regression
> > 	3/ patch is merged in DPDK
> > 	4/ Intel merges it in the internal base code
> > 	5/ Linux kernel team can backport the fix to Linux
> > 	6/ Any other OS can backport the fix in its driver
> 
> Right now, our base code in kernel is GPL license only,
> code with BSD-3-clause can't be distrusted without change our license strategy, 
> so it's the same effort if someone want to backport DPDK changes to kernel
> (shared the copy right to Intel)
> 
> but I like your suggestion (if I understand correctly),
> have a dual licenses in kernel base code make things smoothly
> to backport from DPDK to kernel, I will feedback this.
> 
> > Let's make the DPDK process open for everybody.
> 
> For sure, we should.

RE: [PATCH v2] ixgbe/base: Manual AN-37 for troublesome link partners for X550 SFI

[Zhang, Qi Z]

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Tuesday, May 24, 2022 11:55 PM
> To: Zhang, Qi Z <qi.z.zhang@intel.com>
> Cc: Daly, Jeff <jeffd@silicom-usa.com>; dev@dpdk.org; Wang, Haiyue
> <haiyue.wang@intel.com>; ferruh.yigit@amd.com;
> andrew.rybchenko@oktetlabs.ru; Richardson, Bruce
> <bruce.richardson@intel.com>; Mcnamara, John
> <john.mcnamara@intel.com>
> Subject: Re: [PATCH v2] ixgbe/base: Manual AN-37 for troublesome link
> partners for X550 SFI
> 
> 24/05/2022 15:42, Zhang, Qi Z:
> > From: Thomas Monjalon <thomas@monjalon.net>
> > > 18/05/2022 02:03, Zhang, Qi Z:
> > > > From: Jeff Daly <jeffd@silicom-usa.com>
> > > > >
> > > > > Some SFP link partners exhibit a disinclination to autonegotiate
> > > > > with X550 configured in SFI mode.  This patch enables a manual
> > > > > AN-37 restart to work around the problem.
> > > >
> > > > This fix for some specific hardware in base code, unfortunately
> > > > Intel DPDK team don't have the device and the knowledge to approve
> > > > this,
> > >
> > > That's why the work is collaborative.
> > > You should get and trust knowledge from partners.
> > > The only concerns of a maintainer should be:
> > > 	- good feature design
> > > 	- good code quality
> >
> > These are the questions we can't answer, we don't understand the
> > design, what is " change mode enforcement rules to hybrid " means,
> > what is manual AN-37 here and what those numbers in the patch means.
> 
> So these are the basic questions you should ask to be made clear in the patch.
> That's the same for everybody: we must understand the reason and the
> intent of any change.
> 
> > Of cause we trust knowledge from our partners, but anyway this is an
> > Intel product,
> 
> The DPDK driver is not an Intel product.
> This a community effort where anyone should be able to participate.

I'm taking about the hardware not the driver.

> 
> > only Intel have the right to authenticate this.
> 
> What do you mean by "authenticate"?
> 
> > unfortunately none of the active ixgbe DPDK maintainers and I have the
> > knowledge Meanwhile if this is an issue on DPDK, it could also be an
> > issue on kernel driver that's why we suggest to submit to Linux
> > community first where will be right people to answer above questions.
> 
> Why Linux community is more able to review than DPDK, or FreeBSD, or
> Windows, or any other community?

Of cause DPDK could be able to,  if the people have the corresponding knowledge that works on it
I would say on this very specific domain, DPDK community has the gap that depends on Intel,
Nothing else, we just try to provide workable suggestion based on current situation, meanwhile we will escalate.  

> 
> > > 	- no regression in known cases
> >
> > > > the base code is delivered by our kernel software team, I will
> > > > suggest you can send this to the kernel community to get the right
> > > > expert to review.
> > >
> > > Which kind of expert do you imagine to review?
> > > Intel team or Silicom people who are pushing these improvements?
> >
> > > There is another problem with asking Linux kernel change first:
> > > the patch will land in GPL code, bringing difficulties to move in
> > > BSD-licensed base code.
> >
> > Only if the author agree to share the copy right to Intel, so Intel is
> > able to re-license it to BSD as same as other base code.
> 
> Yes we should be able to grant such copyright in the commit message.
> 
> > > I suggest we make this process more flexible:
> > > 	1/ a contributor sends a patch for DPDK base code
> > > 	   with an explicit grant for backporting in any license.
> > > 	2/ Intel checks that there is no DPDK regression
> > > 	3/ patch is merged in DPDK
> > > 	4/ Intel merges it in the internal base code
> > > 	5/ Linux kernel team can backport the fix to Linux
> > > 	6/ Any other OS can backport the fix in its driver
> >
> > Right now, our base code in kernel is GPL license only, code with
> > BSD-3-clause can't be distrusted without change our license strategy,
> > so it's the same effort if someone want to backport DPDK changes to
> > kernel (shared the copy right to Intel)
> >
> > but I like your suggestion (if I understand correctly), have a dual
> > licenses in kernel base code make things smoothly to backport from
> > DPDK to kernel, I will feedback this.
> >
> > > Let's make the DPDK process open for everybody.
> >
> > For sure, we should.
> 
> 

Re: [PATCH v2] ixgbe/base: Manual AN-37 for troublesome link partners for X550 SFI

[Thomas Monjalon]

25/05/2022 02:11, Zhang, Qi Z:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 24/05/2022 15:42, Zhang, Qi Z:
> > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > 18/05/2022 02:03, Zhang, Qi Z:
> > > > > From: Jeff Daly <jeffd@silicom-usa.com>
> > > > > >
> > > > > > Some SFP link partners exhibit a disinclination to autonegotiate
> > > > > > with X550 configured in SFI mode.  This patch enables a manual
> > > > > > AN-37 restart to work around the problem.
> > > > >
> > > > > This fix for some specific hardware in base code, unfortunately
> > > > > Intel DPDK team don't have the device and the knowledge to approve
> > > > > this,
> > > >
> > > > That's why the work is collaborative.
> > > > You should get and trust knowledge from partners.
> > > > The only concerns of a maintainer should be:
> > > > 	- good feature design
> > > > 	- good code quality
> > >
> > > These are the questions we can't answer, we don't understand the
> > > design, what is " change mode enforcement rules to hybrid " means,
> > > what is manual AN-37 here and what those numbers in the patch means.
> > 
> > So these are the basic questions you should ask to be made clear in the patch.
> > That's the same for everybody: we must understand the reason and the
> > intent of any change.
> > 
> > > Of cause we trust knowledge from our partners, but anyway this is an
> > > Intel product,
> > 
> > The DPDK driver is not an Intel product.
> > This a community effort where anyone should be able to participate.
> 
> I'm taking about the hardware not the driver.

The SFP is not an Intel product.

> > > only Intel have the right to authenticate this.
> > 
> > What do you mean by "authenticate"?

You forgot this question.
What do you mean by "authenticate"?

> > > unfortunately none of the active ixgbe DPDK maintainers and I have the
> > > knowledge Meanwhile if this is an issue on DPDK, it could also be an
> > > issue on kernel driver that's why we suggest to submit to Linux
> > > community first where will be right people to answer above questions.
> > 
> > Why Linux community is more able to review than DPDK, or FreeBSD, or
> > Windows, or any other community?
> 
> Of cause DPDK could be able to,  if the people have the corresponding knowledge that works on it
> I would say on this very specific domain, DPDK community has the gap that depends on Intel,
> Nothing else, we just try to provide workable suggestion based on current situation, meanwhile we will escalate.

You can get the knowledge by asking the right questions.

> > > > 	- no regression in known cases
> > >
> > > > > the base code is delivered by our kernel software team, I will
> > > > > suggest you can send this to the kernel community to get the right
> > > > > expert to review.
> > > >
> > > > Which kind of expert do you imagine to review?
> > > > Intel team or Silicom people who are pushing these improvements?
> > >
> > > > There is another problem with asking Linux kernel change first:
> > > > the patch will land in GPL code, bringing difficulties to move in
> > > > BSD-licensed base code.
> > >
> > > Only if the author agree to share the copy right to Intel, so Intel is
> > > able to re-license it to BSD as same as other base code.
> > 
> > Yes we should be able to grant such copyright in the commit message.
> > 
> > > > I suggest we make this process more flexible:
> > > > 	1/ a contributor sends a patch for DPDK base code
> > > > 	   with an explicit grant for backporting in any license.
> > > > 	2/ Intel checks that there is no DPDK regression
> > > > 	3/ patch is merged in DPDK
> > > > 	4/ Intel merges it in the internal base code
> > > > 	5/ Linux kernel team can backport the fix to Linux
> > > > 	6/ Any other OS can backport the fix in its driver
> > >
> > > Right now, our base code in kernel is GPL license only, code with
> > > BSD-3-clause can't be distrusted without change our license strategy,
> > > so it's the same effort if someone want to backport DPDK changes to
> > > kernel (shared the copy right to Intel)
> > >
> > > but I like your suggestion (if I understand correctly), have a dual
> > > licenses in kernel base code make things smoothly to backport from
> > > DPDK to kernel, I will feedback this.
> > >
> > > > Let's make the DPDK process open for everybody.
> > >
> > > For sure, we should.

RE: [PATCH v2] ixgbe/base: Manual AN-37 for troublesome link partners for X550 SFI

[Zhang, Qi Z]

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Wednesday, May 25, 2022 3:56 PM
> To: Zhang, Qi Z <qi.z.zhang@intel.com>
> Cc: Daly, Jeff <jeffd@silicom-usa.com>; dev@dpdk.org; Wang, Haiyue
> <haiyue.wang@intel.com>; ferruh.yigit@amd.com;
> andrew.rybchenko@oktetlabs.ru; Richardson, Bruce
> <bruce.richardson@intel.com>; Mcnamara, John
> <john.mcnamara@intel.com>
> Subject: Re: [PATCH v2] ixgbe/base: Manual AN-37 for troublesome link
> partners for X550 SFI
> 
> 25/05/2022 02:11, Zhang, Qi Z:
> > From: Thomas Monjalon <thomas@monjalon.net>
> > > 24/05/2022 15:42, Zhang, Qi Z:
> > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > 18/05/2022 02:03, Zhang, Qi Z:
> > > > > > From: Jeff Daly <jeffd@silicom-usa.com>
> > > > > > >
> > > > > > > Some SFP link partners exhibit a disinclination to
> > > > > > > autonegotiate with X550 configured in SFI mode.  This patch
> > > > > > > enables a manual
> > > > > > > AN-37 restart to work around the problem.
> > > > > >
> > > > > > This fix for some specific hardware in base code,
> > > > > > unfortunately Intel DPDK team don't have the device and the
> > > > > > knowledge to approve this,
> > > > >
> > > > > That's why the work is collaborative.
> > > > > You should get and trust knowledge from partners.
> > > > > The only concerns of a maintainer should be:
> > > > > 	- good feature design
> > > > > 	- good code quality
> > > >
> > > > These are the questions we can't answer, we don't understand the
> > > > design, what is " change mode enforcement rules to hybrid " means,
> > > > what is manual AN-37 here and what those numbers in the patch means.
> > >
> > > So these are the basic questions you should ask to be made clear in the
> patch.
> > > That's the same for everybody: we must understand the reason and the
> > > intent of any change.
> > >
> > > > Of cause we trust knowledge from our partners, but anyway this is
> > > > an Intel product,
> > >
> > > The DPDK driver is not an Intel product.
> > > This a community effort where anyone should be able to participate.
> >
> > I'm taking about the hardware not the driver.
> 
> The SFP is not an Intel product.

I'm talking about supported ixgbe NICs , that's patch will impact.
https://doc.dpdk.org/guides/nics/ixgbe.html

> 
> > > > only Intel have the right to authenticate this.
> > >
> > > What do you mean by "authenticate"?
> 
> You forgot this question.
> What do you mean by "authenticate"?

I mean a hardware vendor to judge if a configure is correct or not on its own product.
Btw, I may not express this clearly in previous, I would say "responsibility"  but not the "right"

> 
> > > > unfortunately none of the active ixgbe DPDK maintainers and I have
> > > > the knowledge Meanwhile if this is an issue on DPDK, it could also
> > > > be an issue on kernel driver that's why we suggest to submit to
> > > > Linux community first where will be right people to answer above
> questions.
> > >
> > > Why Linux community is more able to review than DPDK, or FreeBSD, or
> > > Windows, or any other community?
> >
> > Of cause DPDK could be able to,  if the people have the corresponding
> > knowledge that works on it I would say on this very specific domain,
> > DPDK community has the gap that depends on Intel, Nothing else, we just
> try to provide workable suggestion based on current situation, meanwhile
> we will escalate.
> 
> You can get the knowledge by asking the right questions.
> 
> > > > > 	- no regression in known cases
> > > >
> > > > > > the base code is delivered by our kernel software team, I will
> > > > > > suggest you can send this to the kernel community to get the
> > > > > > right expert to review.
> > > > >
> > > > > Which kind of expert do you imagine to review?
> > > > > Intel team or Silicom people who are pushing these improvements?
> > > >
> > > > > There is another problem with asking Linux kernel change first:
> > > > > the patch will land in GPL code, bringing difficulties to move
> > > > > in BSD-licensed base code.
> > > >
> > > > Only if the author agree to share the copy right to Intel, so
> > > > Intel is able to re-license it to BSD as same as other base code.
> > >
> > > Yes we should be able to grant such copyright in the commit message.
> > >
> > > > > I suggest we make this process more flexible:
> > > > > 	1/ a contributor sends a patch for DPDK base code
> > > > > 	   with an explicit grant for backporting in any license.
> > > > > 	2/ Intel checks that there is no DPDK regression
> > > > > 	3/ patch is merged in DPDK
> > > > > 	4/ Intel merges it in the internal base code
> > > > > 	5/ Linux kernel team can backport the fix to Linux
> > > > > 	6/ Any other OS can backport the fix in its driver
> > > >
> > > > Right now, our base code in kernel is GPL license only, code with
> > > > BSD-3-clause can't be distrusted without change our license
> > > > strategy, so it's the same effort if someone want to backport DPDK
> > > > changes to kernel (shared the copy right to Intel)
> > > >
> > > > but I like your suggestion (if I understand correctly), have a
> > > > dual licenses in kernel base code make things smoothly to backport
> > > > from DPDK to kernel, I will feedback this.
> > > >
> > > > > Let's make the DPDK process open for everybody.
> > > >
> > > > For sure, we should.
> 
>