All of lore.kernel.org
 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 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.