From: "Marek Behún" <kabel@kernel.org>
To: Eric Woudstra <ericwouds@gmail.com>
Cc: netdev@vger.kernel.org, Russell King <rmk+kernel@armlinux.org.uk>,
Raju Lakkaraju <Raju.Lakkaraju@microchip.com>,
Frank Wunderlich <frank-w@public-files.de>,
Simon Horman <simon.horman@corigine.com>,
Andrew Lunn <andrew@lunn.ch>,
Heiner Kallweit <hkallweit1@gmail.com>
Subject: Re: [PATCH net-next 2/2] net: sfp: enhance quirk for Fibrestore 2.5G copper SFP module
Date: Tue, 23 Apr 2024 10:40:41 +0200 [thread overview]
Message-ID: <20240423104041.080a9876@dellmb> (raw)
In-Reply-To: <ea9924d3-639b-4332-b870-a9ab2caab11c@gmail.com>
On Tue, 23 Apr 2024 07:54:39 +0200
Eric Woudstra <ericwouds@gmail.com> wrote:
> On 4/22/24 11:44, Marek Behún wrote:
>
> > Frank, Russell, do you still have access to OEM SFP-2.5G-T module?
> > It could make sense to try this quirk also for those modeuls, instead
> > of the current sfp_quirk_oem_2_5
>
> It was part of the previous patch-set until and including v2:
> "rtl8221b/8251b add C45 instances and SerDes switching"
>
> Note that it does:
> sfp->id.base.extended_cc = SFF8024_ECC_2_5GBASE_T;
> As the OEM modules have not set this byte. We need it, so that we know
> that the sfp_may_have_phy().
>
> After v2 I have dropped it, as it would break functioning some sfp-modules.
>
> As OEM vendors know the eeprom password of the Rollball sfp modules,
> they use it in any way they want, not taking in to account that mainline
> kernel uses it for unique identification.
>
> Vendor 1 sells "OEM", "SFP-2.5G-T" with a rtl8221b on it.
> Vendor 2 sells "OEM", "SFP-2.5G-T" with a yt8821 on it.
>
> So on the OEM modules, we cannot rely solely on the two strings anymore.
>
> Introducing the patch, would break the modules with the yt8821 on it. It
> does not have any support in mainline.
>
> Also any code I found for the yt8821 is C22 only. And even more, even
> though we are facing with an almost similar MCU, RollBall protocol does
> not work. I think it is almost the same mcu, as it responds to the same
> eeprom password, and also the rollball password does something, but not
> give the expected result.
>
What about I2C address 0x56?
I noticed that the Fibrestore FS SFP-2.5G-T with the realtek chip
also exposes clause 22 registers, but the current mdio-i2c driver wont
work, because the module implements the access in an incompatible way
(we would need to extend mdio-i2c).
Eric, can you check whether the motorcomm module exposes something on
address 0x56? With i2cdump, i.e. on omnia:
i2cdump -y 5 0x56
(you will need to change 5 to the i2c controller of the sfp cage).
What does it print?
Marek
next prev parent reply other threads:[~2024-04-23 8:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-22 9:44 [PATCH net-next 1/2] net: sfp: update comment for FS SFP-10G-T quirk Marek Behún
2024-04-22 9:44 ` [PATCH net-next 2/2] net: sfp: enhance quirk for Fibrestore 2.5G copper SFP module Marek Behún
2024-04-22 13:12 ` Andrew Lunn
2024-04-22 13:43 ` Marek Behún
2024-04-23 5:54 ` Eric Woudstra
2024-04-23 8:40 ` Marek Behún [this message]
2024-04-23 8:51 ` Eric Woudstra
2024-04-23 10:17 ` Marek Behún
2024-04-22 13:09 ` [PATCH net-next 1/2] net: sfp: update comment for FS SFP-10G-T quirk Andrew Lunn
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=20240423104041.080a9876@dellmb \
--to=kabel@kernel.org \
--cc=Raju.Lakkaraju@microchip.com \
--cc=andrew@lunn.ch \
--cc=ericwouds@gmail.com \
--cc=frank-w@public-files.de \
--cc=hkallweit1@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=rmk+kernel@armlinux.org.uk \
--cc=simon.horman@corigine.com \
/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.