From: Florian Fainelli <f.fainelli@gmail.com>
To: Chris Healy <cphealy@gmail.com>,
linux@armlinux.org.uk, andrew@lunn.ch, hkallweit1@gmail.com,
davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next] net: phy: sfp: Cotsworks SFF module EEPROM fixup
Date: Wed, 15 Jul 2020 20:10:54 -0700 [thread overview]
Message-ID: <be18cbb8-4deb-ebdc-1097-7b1453bcf86e@gmail.com> (raw)
In-Reply-To: <20200714175910.1358-1-cphealy@gmail.com>
On 7/14/2020 10:59 AM, Chris Healy wrote:
> Some Cotsworks SFF have invalid data in the first few bytes of the
> module EEPROM. This results in these modules not being detected as
> valid modules.
>
> Address this by poking the correct EEPROM values into the module
> EEPROM when the model/PN match and the existing module EEPROM contents
> are not correct.
>
> Signed-off-by: Chris Healy <cphealy@gmail.com>
> ---
> drivers/net/phy/sfp.c | 44 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 44 insertions(+)
>
> diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
> index 73c2969f11a4..2737d9b6b0ae 100644
> --- a/drivers/net/phy/sfp.c
> +++ b/drivers/net/phy/sfp.c
> @@ -1632,10 +1632,43 @@ static int sfp_sm_mod_hpower(struct sfp *sfp, bool enable)
> return 0;
> }
>
> +static int sfp_cotsworks_fixup_check(struct sfp *sfp, struct sfp_eeprom_id *id)
> +{
> + u8 check;
> + int err;
> +
> + if (id->base.phys_id != SFF8024_ID_SFF_8472 ||
> + id->base.phys_ext_id != SFP_PHYS_EXT_ID_SFP ||
> + id->base.connector != SFF8024_CONNECTOR_LC) {
> + dev_warn(sfp->dev, "Rewriting fiber module EEPROM with corrected values\n");
> + id->base.phys_id = SFF8024_ID_SFF_8472;
> + id->base.phys_ext_id = SFP_PHYS_EXT_ID_SFP;
> + id->base.connector = SFF8024_CONNECTOR_LC;
> + err = sfp_write(sfp, false, SFP_PHYS_ID, &id->base, 3);
> + if (err != 3) {
> + dev_err(sfp->dev, "Failed to rewrite module EEPROM: %d\n", err);
> + return err;
> + }
> +
> + /* Cotsworks modules have been found to require a delay between write operations. */
> + mdelay(50);
> +
> + /* Update base structure checksum */
> + check = sfp_check(&id->base, sizeof(id->base) - 1);
> + err = sfp_write(sfp, false, SFP_CC_BASE, &check, 1);
> + if (err != 1) {
> + dev_err(sfp->dev, "Failed to update base structure checksum in fiber module EEPROM: %d\n", err);
> + return err;
> + }
> + }
> + return 0;
> +}
> +
> static int sfp_sm_mod_probe(struct sfp *sfp, bool report)
> {
> /* SFP module inserted - read I2C data */
> struct sfp_eeprom_id id;
> + bool cotsworks_sfbg;
> bool cotsworks;
> u8 check;
> int ret;
> @@ -1657,6 +1690,17 @@ static int sfp_sm_mod_probe(struct sfp *sfp, bool report)
> * serial number and date code.
> */
> cotsworks = !memcmp(id.base.vendor_name, "COTSWORKS ", 16);
> + cotsworks_sfbg = !memcmp(id.base.vendor_pn, "SFBG", 4);
> +
> + /* Cotsworks SFF module EEPROM do not always have valid phys_id,
> + * phys_ext_id, and connector bytes. Rewrite SFF EEPROM bytes if
> + * Cotsworks PN matches and bytes are not correct.
> + */
> + if (cotsworks && cotsworks_sfbg) {
> + ret = sfp_cotsworks_fixup_check(sfp, &id);
> + if (ret < 0)
> + return ret;
> + }
So with the fixup you introduce, should we ever go into a situation where:
EPROM extended structure checksum failure
is printed?
--
Florian
next prev parent reply other threads:[~2020-07-16 3:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-14 17:59 [PATCH net-next] net: phy: sfp: Cotsworks SFF module EEPROM fixup Chris Healy
2020-07-16 3:10 ` Florian Fainelli [this message]
[not found] ` <CAFXsbZpHH3rFbxG1-bGOErQZS+_3Xo8rAKDSWwgH3M7Bgj_sGw@mail.gmail.com>
2020-07-16 3:37 ` Florian Fainelli
2020-07-17 17:33 ` David Miller
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=be18cbb8-4deb-ebdc-1097-7b1453bcf86e@gmail.com \
--to=f.fainelli@gmail.com \
--cc=andrew@lunn.ch \
--cc=cphealy@gmail.com \
--cc=davem@davemloft.net \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.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