netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Andrew Lunn <andrew@lunn.ch>, Heiner Kallweit <hkallweit1@gmail.com>
Cc: "Pali Rohár" <pali@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	"Jakub Kicinski" <kuba@kernel.org>,
	netdev@vger.kernel.org
Subject: Re: [PATCH net-next 1/2] net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround
Date: Fri, 4 Dec 2020 15:00:05 +0000	[thread overview]
Message-ID: <20201204150005.GM1551@shell.armlinux.org.uk> (raw)
In-Reply-To: <E1klCB8-0001sW-Ma@rmk-PC.armlinux.org.uk>

... and I just got another email from Pali Rohár about an hour after
giving me a Tested-by for this patch, saying...

Just to note I applied following fixup change to your patches for
fixing compile errors, there is missing "struct" keyword...

So, v2 on its way.

On Fri, Dec 04, 2020 at 02:35:22PM +0000, Russell King wrote:
> Add a workaround for the detection of VSOL V2801F / CarlitoxxPro
> CPGOS03-0490 v2.0 GPON module which CarlitoxxPro states needs single
> byte I2C reads to the EEPROM.
> 
> Pali Rohár reports that he also has a CarlitoxxPro-based V2801F module,
> which reports a manufacturer of "OEM". This manufacturer can't be
> matched as it appears in many different modules, so also match the part
> number too.
> 
> Reported-by: Thomas Schreiber <tschreibe@gmail.com>
> Reported-by: Pali Rohár <pali@kernel.org>
> Tested-by: Pali Rohár <pali@kernel.org>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
>  drivers/net/phy/sfp.c | 63 +++++++++++++++++++++++++++++++++++++++----
>  1 file changed, 58 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
> index 34aa196b7465..0b26495973ff 100644
> --- a/drivers/net/phy/sfp.c
> +++ b/drivers/net/phy/sfp.c
> @@ -219,6 +219,7 @@ struct sfp {
>  	struct sfp_bus *sfp_bus;
>  	struct phy_device *mod_phy;
>  	const struct sff_data *type;
> +	size_t i2c_block_size;
>  	u32 max_power_mW;
>  
>  	unsigned int (*get_state)(struct sfp *);
> @@ -335,10 +336,19 @@ static int sfp_i2c_read(struct sfp *sfp, bool a2, u8 dev_addr, void *buf,
>  			size_t len)
>  {
>  	struct i2c_msg msgs[2];
> -	u8 bus_addr = a2 ? 0x51 : 0x50;
> +	size_t block_size;
>  	size_t this_len;
> +	u8 bus_addr;
>  	int ret;
>  
> +	if (a2) {
> +		block_size = 16;
> +		bus_addr = 0x51;
> +	} else {
> +		block_size = sfp->i2c_block_size;
> +		bus_addr = 0x50;
> +	}
> +
>  	msgs[0].addr = bus_addr;
>  	msgs[0].flags = 0;
>  	msgs[0].len = 1;
> @@ -350,8 +360,8 @@ static int sfp_i2c_read(struct sfp *sfp, bool a2, u8 dev_addr, void *buf,
>  
>  	while (len) {
>  		this_len = len;
> -		if (this_len > 16)
> -			this_len = 16;
> +		if (this_len > block_size)
> +			this_len = block_size;
>  
>  		msgs[1].len = this_len;
>  
> @@ -1632,6 +1642,28 @@ static int sfp_sm_mod_hpower(struct sfp *sfp, bool enable)
>  	return 0;
>  }
>  
> +/* Some modules (Nokia 3FE46541AA) lock up if byte 0x51 is read as a
> + * single read. Switch back to reading 16 byte blocks unless we have
> + * a CarlitoxxPro module (rebranded VSOL V2801F). Even more annoyingly,
> + * some VSOL V2801F have the vendor name changed to OEM.
> + */
> +static int sfp_quirk_i2c_block_size(const sfp_eeprom_base *base)
> +{
> +	if (!memcmp(base->vendor_name, "VSOL            ", 16))
> +		return 1;
> +	if (!memcmp(base->vendor_name, "OEM             ", 16) &&
> +	    !memcmp(base->vendor_pn,   "V2801F          ", 16))
> +		return 1;
> +
> +	/* Some modules can't cope with long reads */
> +	return 16;
> +}
> +
> +static void sfp_quirks_base(struct sfp *sfp, const sfp_eeprom_base *base)
> +{
> +	sfp->i2c_block_size = sfp_quirk_i2c_block_size(base);
> +}
> +
>  static int sfp_cotsworks_fixup_check(struct sfp *sfp, struct sfp_eeprom_id *id)
>  {
>  	u8 check;
> @@ -1673,14 +1705,20 @@ static int sfp_sm_mod_probe(struct sfp *sfp, bool report)
>  	u8 check;
>  	int ret;
>  
> -	ret = sfp_read(sfp, false, 0, &id, sizeof(id));
> +	/* Some modules (CarlitoxxPro CPGOS03-0490) do not support multibyte
> +	 * reads from the EEPROM, so start by reading the base identifying
> +	 * information one byte at a time.
> +	 */
> +	sfp->i2c_block_size = 1;
> +
> +	ret = sfp_read(sfp, false, 0, &id.base, sizeof(id.base));
>  	if (ret < 0) {
>  		if (report)
>  			dev_err(sfp->dev, "failed to read EEPROM: %d\n", ret);
>  		return -EAGAIN;
>  	}
>  
> -	if (ret != sizeof(id)) {
> +	if (ret != sizeof(id.base)) {
>  		dev_err(sfp->dev, "EEPROM short read: %d\n", ret);
>  		return -EAGAIN;
>  	}
> @@ -1719,6 +1757,21 @@ static int sfp_sm_mod_probe(struct sfp *sfp, bool report)
>  		}
>  	}
>  
> +	/* Apply any early module-specific quirks */
> +	sfp_quirks_base(sfp, &id.base);
> +
> +	ret = sfp_read(sfp, false, SFP_CC_BASE + 1, &id.ext, sizeof(id.ext));
> +	if (ret < 0) {
> +		if (report)
> +			dev_err(sfp->dev, "failed to read EEPROM: %d\n", ret);
> +		return -EAGAIN;
> +	}
> +
> +	if (ret != sizeof(id.ext)) {
> +		dev_err(sfp->dev, "EEPROM short read: %d\n", ret);
> +		return -EAGAIN;
> +	}
> +
>  	check = sfp_check(&id.ext, sizeof(id.ext) - 1);
>  	if (check != id.ext.cc_ext) {
>  		if (cotsworks) {
> -- 
> 2.20.1
> 
> 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

  parent reply	other threads:[~2020-12-04 15:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-04 14:34 [PATCH net-next 0/2] Add support for VSOL V2801F/CarlitoxxPro CPGOS03 GPON module Russell King - ARM Linux admin
     [not found] ` <E1klCB8-0001sW-Ma@rmk-PC.armlinux.org.uk>
2020-12-04 15:00   ` Russell King - ARM Linux admin [this message]
2020-12-04 15:31   ` [PATCH net-next 1/2] net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround Andrew Lunn
2020-12-09 11:20     ` Russell King - ARM Linux admin
     [not found] ` <E1klCBD-0001si-Qj@rmk-PC.armlinux.org.uk>
2020-12-04 15:38   ` [PATCH net-next 2/2] net: sfp: relax bitrate-derived mode check Andrew Lunn
2020-12-04 15:51     ` Russell King - ARM Linux admin
2020-12-09 11:11 ` [PATCH net-next 0/2] Add support for VSOL V2801F/CarlitoxxPro CPGOS03 GPON module Russell King - ARM Linux admin
2020-12-09 11:17   ` Russell King - ARM Linux admin
  -- strict thread matches above, loose matches on Subject: below --
2020-12-09 11:21 [PATCH RESEND " Russell King - ARM Linux admin
2020-12-09 11:22 ` [PATCH net-next 1/2] net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround Russell King

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=20201204150005.GM1551@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pali@kernel.org \
    /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).