[PATCH] sfp: allow cotsworks modules

[PATCH] sfp: allow cotsworks modules

[Russell King]

Cotsworks modules fail the checksums - it appears that Cotsworks
reprograms the EEPROM at the end of production with the final product
information (serial, date code, and exact part number for module
options) and fails to update the checksum.

Work around this by detecting the Cotsworks name in the manufacturer
field, and reducing the checksum failures to warnings rather than a
hard error.

Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
 drivers/net/phy/sfp.c | 41 +++++++++++++++++++++++++++++++----------
 1 file changed, 31 insertions(+), 10 deletions(-)

diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 83bf4959b043..4ab6e9a50bbe 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -560,6 +560,7 @@ static int sfp_sm_mod_probe(struct sfp *sfp)
 {
 	/* SFP module inserted - read I2C data */
 	struct sfp_eeprom_id id;
+	bool cotsworks;
 	u8 check;
 	int ret;
 
@@ -574,23 +575,43 @@ static int sfp_sm_mod_probe(struct sfp *sfp)
 		return -EAGAIN;
 	}
 
+	/* Cotsworks do not seem to update the checksums when they
+	 * do the final programming with the final module part number,
+	 * serial number and date code.
+	 */
+	cotsworks = !memcmp(id.base.vendor_name, "COTSWORKS       ", 16);
+
 	/* Validate the checksum over the base structure */
 	check = sfp_check(&id.base, sizeof(id.base) - 1);
 	if (check != id.base.cc_base) {
-		dev_err(sfp->dev,
-			"EEPROM base structure checksum failure: 0x%02x\n",
-			check);
-		print_hex_dump(KERN_ERR, "sfp EE: ", DUMP_PREFIX_OFFSET,
-			       16, 1, &id, sizeof(id.base) - 1, true);
-		return -EINVAL;
+		if (cotsworks) {
+			dev_warn(sfp->dev,
+				 "EEPROM base structure checksum failure (0x%02x != 0x%02x)\n",
+				 check, id.base.cc_base);
+		} else {
+			dev_err(sfp->dev,
+				"EEPROM base structure checksum failure: 0x%02x != 0x%02x\n",
+				check, id.base.cc_base);
+			print_hex_dump(KERN_ERR, "sfp EE: ", DUMP_PREFIX_OFFSET,
+				       16, 1, &id, sizeof(id), true);
+			return -EINVAL;
+		}
 	}
 
 	check = sfp_check(&id.ext, sizeof(id.ext) - 1);
 	if (check != id.ext.cc_ext) {
-		dev_err(sfp->dev,
-			"EEPROM extended structure checksum failure: 0x%02x\n",
-			check);
-		memset(&id.ext, 0, sizeof(id.ext));
+		if (cotsworks) {
+			dev_warn(sfp->dev,
+				 "EEPROM extended structure checksum failure (0x%02x != 0x%02x)\n",
+				 check, id.ext.cc_ext);
+		} else {
+			dev_err(sfp->dev,
+				"EEPROM extended structure checksum failure: 0x%02x != 0x%02x\n",
+				check, id.ext.cc_ext);
+			print_hex_dump(KERN_ERR, "sfp EE: ", DUMP_PREFIX_OFFSET,
+				       16, 1, &id, sizeof(id), true);
+			memset(&id.ext, 0, sizeof(id.ext));
+		}
 	}
 
 	sfp->id = id;
-- 
2.7.4

Re: [PATCH] sfp: allow cotsworks modules

[Joe Perches]

On Wed, 2018-03-28 at 11:18 +0100, Russell King wrote:
> Cotsworks modules fail the checksums - it appears that Cotsworks
> reprograms the EEPROM at the end of production with the final product
> information (serial, date code, and exact part number for module
> options) and fails to update the checksum.

trivia:

> diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
[]
> @@ -574,23 +575,43 @@ static int sfp_sm_mod_probe(struct sfp *sfp)
[]
> +		if (cotsworks) {
> +			dev_warn(sfp->dev,
> +				 "EEPROM base structure checksum failure (0x%02x != 0x%02x)\n",
> +				 check, id.base.cc_base);
> +		} else {
> +			dev_err(sfp->dev,
> +				"EEPROM base structure checksum failure: 0x%02x != 0x%02x\n",

It'd be better to move this above the if and
use only a single format string instead of
using 2 slightly different formats.

> +				check, id.base.cc_base);
> +			print_hex_dump(KERN_ERR, "sfp EE: ", DUMP_PREFIX_OFFSET,
> +				       16, 1, &id, sizeof(id), true);
> +			return -EINVAL;
> +		}
>  	}
>  
>  	check = sfp_check(&id.ext, sizeof(id.ext) - 1);
>  	if (check != id.ext.cc_ext) {
> -		dev_err(sfp->dev,
> -			"EEPROM extended structure checksum failure: 0x%02x\n",
> -			check);
> -		memset(&id.ext, 0, sizeof(id.ext));
> +		if (cotsworks) {
> +			dev_warn(sfp->dev,
> +				 "EEPROM extended structure checksum failure (0x%02x != 0x%02x)\n",
> +				 check, id.ext.cc_ext);
> +		} else {
> +			dev_err(sfp->dev,
> +				"EEPROM extended structure checksum failure: 0x%02x != 0x%02x\n",
> +				check, id.ext.cc_ext);


here too

Re: [PATCH] sfp: allow cotsworks modules

[Russell King - ARM Linux]

On Wed, Mar 28, 2018 at 03:33:57AM -0700, Joe Perches wrote:
> On Wed, 2018-03-28 at 11:18 +0100, Russell King wrote:
> > Cotsworks modules fail the checksums - it appears that Cotsworks
> > reprograms the EEPROM at the end of production with the final product
> > information (serial, date code, and exact part number for module
> > options) and fails to update the checksum.
> 
> trivia:
> 
> > diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
> []
> > @@ -574,23 +575,43 @@ static int sfp_sm_mod_probe(struct sfp *sfp)
> []
> > +		if (cotsworks) {
> > +			dev_warn(sfp->dev,
> > +				 "EEPROM base structure checksum failure (0x%02x != 0x%02x)\n",
> > +				 check, id.base.cc_base);
> > +		} else {
> > +			dev_err(sfp->dev,
> > +				"EEPROM base structure checksum failure: 0x%02x != 0x%02x\n",
> 
> It'd be better to move this above the if and
> use only a single format string instead of
> using 2 slightly different formats.

No.  I think you've missed the fact that one is a _warning_ the other is
an _error_ and they are emitted at the appropriate severity.  It's not
just that the format strings are slightly different.

> 
> > +				check, id.base.cc_base);
> > +			print_hex_dump(KERN_ERR, "sfp EE: ", DUMP_PREFIX_OFFSET,
> > +				       16, 1, &id, sizeof(id), true);
> > +			return -EINVAL;
> > +		}
> >  	}
> >  
> >  	check = sfp_check(&id.ext, sizeof(id.ext) - 1);
> >  	if (check != id.ext.cc_ext) {
> > -		dev_err(sfp->dev,
> > -			"EEPROM extended structure checksum failure: 0x%02x\n",
> > -			check);
> > -		memset(&id.ext, 0, sizeof(id.ext));
> > +		if (cotsworks) {
> > +			dev_warn(sfp->dev,
> > +				 "EEPROM extended structure checksum failure (0x%02x != 0x%02x)\n",
> > +				 check, id.ext.cc_ext);
> > +		} else {
> > +			dev_err(sfp->dev,
> > +				"EEPROM extended structure checksum failure: 0x%02x != 0x%02x\n",
> > +				check, id.ext.cc_ext);
> 
> 
> here too

Same applies.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCH] sfp: allow cotsworks modules

[Joe Perches]

On Wed, 2018-03-28 at 11:41 +0100, Russell King - ARM Linux wrote:
> On Wed, Mar 28, 2018 at 03:33:57AM -0700, Joe Perches wrote:
> > On Wed, 2018-03-28 at 11:18 +0100, Russell King wrote:
> > > Cotsworks modules fail the checksums - it appears that Cotsworks
> > > reprograms the EEPROM at the end of production with the final product
> > > information (serial, date code, and exact part number for module
> > > options) and fails to update the checksum.
> > 
> > trivia:
> > 
> > > diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
> > 
> > []
> > > @@ -574,23 +575,43 @@ static int sfp_sm_mod_probe(struct sfp *sfp)
> > 
> > []
> > > +		if (cotsworks) {
> > > +			dev_warn(sfp->dev,
> > > +				 "EEPROM base structure checksum failure (0x%02x != 0x%02x)\n",
> > > +				 check, id.base.cc_base);
> > > +		} else {
> > > +			dev_err(sfp->dev,
> > > +				"EEPROM base structure checksum failure: 0x%02x != 0x%02x\n",
> > 
> > It'd be better to move this above the if and
> > use only a single format string instead of
> > using 2 slightly different formats.
> 
> No.  I think you've missed the fact that one is a _warning_ the other is
> an _error_ and they are emitted at the appropriate severity.  It's not
> just that the format strings are slightly different.

Right.  Still nicer to use the same formats.

cheers, Joe

Re: [PATCH] sfp: allow cotsworks modules

[Russell King - ARM Linux]

On Wed, Mar 28, 2018 at 09:19:01AM -0700, Joe Perches wrote:
> On Wed, 2018-03-28 at 11:41 +0100, Russell King - ARM Linux wrote:
> > On Wed, Mar 28, 2018 at 03:33:57AM -0700, Joe Perches wrote:
> > > On Wed, 2018-03-28 at 11:18 +0100, Russell King wrote:
> > > > Cotsworks modules fail the checksums - it appears that Cotsworks
> > > > reprograms the EEPROM at the end of production with the final product
> > > > information (serial, date code, and exact part number for module
> > > > options) and fails to update the checksum.
> > > 
> > > trivia:
> > > 
> > > > diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
> > > 
> > > []
> > > > @@ -574,23 +575,43 @@ static int sfp_sm_mod_probe(struct sfp *sfp)
> > > 
> > > []
> > > > +		if (cotsworks) {
> > > > +			dev_warn(sfp->dev,
> > > > +				 "EEPROM base structure checksum failure (0x%02x != 0x%02x)\n",
> > > > +				 check, id.base.cc_base);
> > > > +		} else {
> > > > +			dev_err(sfp->dev,
> > > > +				"EEPROM base structure checksum failure: 0x%02x != 0x%02x\n",
> > > 
> > > It'd be better to move this above the if and
> > > use only a single format string instead of
> > > using 2 slightly different formats.
> > 
> > No.  I think you've missed the fact that one is a _warning_ the other is
> > an _error_ and they are emitted at the appropriate severity.  It's not
> > just that the format strings are slightly different.
> 
> Right.  Still nicer to use the same formats.

I'll stick a "Warning:" and "Error:" tag before them if you really
want the rest of the message to be identically formatted - otherwise,
when seeing reports from people's dmesg, there will be nothing to
indicate which message was printed.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCH] sfp: allow cotsworks modules

[Joe Perches]

On Wed, 2018-03-28 at 17:51 +0100, Russell King - ARM Linux wrote:
> On Wed, Mar 28, 2018 at 09:19:01AM -0700, Joe Perches wrote:
> > On Wed, 2018-03-28 at 11:41 +0100, Russell King - ARM Linux wrote:
> > > On Wed, Mar 28, 2018 at 03:33:57AM -0700, Joe Perches wrote:
> > > > On Wed, 2018-03-28 at 11:18 +0100, Russell King wrote:
> > > > > Cotsworks modules fail the checksums - it appears that Cotsworks
> > > > > reprograms the EEPROM at the end of production with the final product
> > > > > information (serial, date code, and exact part number for module
> > > > > options) and fails to update the checksum.
> > > > 
> > > > trivia:
> > > > 
> > > > > diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
> > > > 
> > > > []
> > > > > @@ -574,23 +575,43 @@ static int sfp_sm_mod_probe(struct sfp *sfp)
> > > > 
> > > > []
> > > > > +		if (cotsworks) {
> > > > > +			dev_warn(sfp->dev,
> > > > > +				 "EEPROM base structure checksum failure (0x%02x != 0x%02x)\n",
> > > > > +				 check, id.base.cc_base);
> > > > > +		} else {
> > > > > +			dev_err(sfp->dev,
> > > > > +				"EEPROM base structure checksum failure: 0x%02x != 0x%02x\n",
> > > > 
> > > > It'd be better to move this above the if and
> > > > use only a single format string instead of
> > > > using 2 slightly different formats.
> > > 
> > > No.  I think you've missed the fact that one is a _warning_ the other is
> > > an _error_ and they are emitted at the appropriate severity.  It's not
> > > just that the format strings are slightly different.
> > 
> > Right.  Still nicer to use the same formats.
> 
> I'll stick a "Warning:" and "Error:" tag before them if you really
> want the rest of the message to be identically formatted - otherwise,
> when seeing reports from people's dmesg, there will be nothing to
> indicate which message was printed.

Not necessary.  It was just a trivial size saving
from the format deduplication.

There is another dmesg info line

	dev_info(sfp->dev, "module %.*s %.*s rev %.*s sn %.*s dc %.*s\n",
		 (int)sizeof(id.base.vendor_name), id.base.vendor_name,
		 (int)sizeof(id.base.vendor_pn), id.base.vendor_pn,
		 (int)sizeof(id.base.vendor_rev), id.base.vendor_rev,
		 (int)sizeof(id.ext.vendor_sn), id.ext.vendor_sn,
		 (int)sizeof(id.ext.datecode), id.ext.datecode);

the next line later which shows that it's a "COTSWORKS       ".

Re: [PATCH] sfp: allow cotsworks modules

[David Miller]

From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Wed, 28 Mar 2018 11:18:25 +0100

> Cotsworks modules fail the checksums - it appears that Cotsworks
> reprograms the EEPROM at the end of production with the final product
> information (serial, date code, and exact part number for module
> options) and fails to update the checksum.
> 
> Work around this by detecting the Cotsworks name in the manufacturer
> field, and reducing the checksum failures to warnings rather than a
> hard error.
> 
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

Applied, thanks Russell.