netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Marek Behun <marek.behun@nic.cz>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH net-next] net: sfp: add some quirks for FreeTel direct attach modules
Date: Fri, 8 May 2020 19:00:24 +0100	[thread overview]
Message-ID: <20200508180024.GX1551@shell.armlinux.org.uk> (raw)
In-Reply-To: <20200508182706.06394c88@nic.cz>

On Fri, May 08, 2020 at 06:27:06PM +0200, Marek Behun wrote:
> On Fri, 8 May 2020 16:28:44 +0100
> Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:
> 
> > On Thu, May 07, 2020 at 03:21:35PM +0200, Marek Behún wrote:
> > > FreeTel P.C30.2 and P.C30.3 may fail to report anything useful from
> > > their EEPROM. They report correct nominal bitrate of 10300 MBd, but do
> > > not report sfp_ct_passive nor sfp_ct_active in their ERPROM.
> > > 
> > > These modules can also operate at 1000baseX and 2500baseX.
> > > 
> > > Signed-off-by: Marek Behún <marek.behun@nic.cz>
> > > Cc: Russell King <rmk+kernel@armlinux.org.uk>
> > > ---
> > >  drivers/net/phy/sfp-bus.c | 20 ++++++++++++++++++++
> > >  1 file changed, 20 insertions(+)
> > > 
> > > diff --git a/drivers/net/phy/sfp-bus.c b/drivers/net/phy/sfp-bus.c
> > > index 6900c68260e0..f021709bedcc 100644
> > > --- a/drivers/net/phy/sfp-bus.c
> > > +++ b/drivers/net/phy/sfp-bus.c
> > > @@ -44,6 +44,14 @@ static void sfp_quirk_2500basex(const struct sfp_eeprom_id *id,
> > >  	phylink_set(modes, 2500baseX_Full);
> > >  }
> > >  
> > > +static void sfp_quirk_direct_attach_10g(const struct sfp_eeprom_id *id,
> > > +					unsigned long *modes)
> > > +{
> > > +	phylink_set(modes, 10000baseCR_Full);
> > > +	phylink_set(modes, 2500baseX_Full);
> > > +	phylink_set(modes, 1000baseX_Full);
> > > +}
> > > +
> > >  static const struct sfp_quirk sfp_quirks[] = {
> > >  	{
> > >  		// Alcatel Lucent G-010S-P can operate at 2500base-X, but
> > > @@ -63,6 +71,18 @@ static const struct sfp_quirk sfp_quirks[] = {
> > >  		.vendor = "HUAWEI",
> > >  		.part = "MA5671A",
> > >  		.modes = sfp_quirk_2500basex,
> > > +	}, {
> > > +		// FreeTel P.C30.2 is a SFP+ direct attach that can operate at
> > > +		// at 1000baseX, 2500baseX and 10000baseCR, but may report none
> > > +		// of these in their EEPROM
> > > +		.vendor = "FreeTel",
> > > +		.part = "P.C30.2",
> > > +		.modes = sfp_quirk_direct_attach_10g,
> > > +	}, {
> > > +		// same as previous
> > > +		.vendor = "FreeTel",
> > > +		.part = "P.C30.3",
> > > +		.modes = sfp_quirk_direct_attach_10g,  
> > 
> > Looking at the EEPROM capabilities, it seems that these modules give
> > either:
> > 
> > Transceiver codes     : 0x01 0x00 0x00 0x00 0x00 0x04 0x80 0x00 0x00
> > Transceiver type      : Infiniband: 1X Copper Passive
> > Transceiver type      : Passive Cable
> > Transceiver type      : FC: Twin Axial Pair (TW)
> > Encoding              : 0x06 (64B/66B)
> > BR, Nominal           : 10300MBd
> > Passive Cu cmplnce.   : 0x01 (SFF-8431 appendix E) [SFF-8472 rev10.4 only]
> > BR margin, max        : 0%
> > BR margin, min        : 0%
> > 
> > or:
> > 
> > Transceiver codes     : 0x00 0x00 0x00 0x00 0x00 0x04 0x80 0x00 0x00
> > Transceiver type      : Passive Cable
> > Transceiver type      : FC: Twin Axial Pair (TW)
> > Encoding              : 0x06 (64B/66B)
> > BR, Nominal           : 10300MBd
> > Passive Cu cmplnce.   : 0x01 (SFF-8431 appendix E) [SFF-8472 rev10.4 only]
> > BR margin, max        : 0%
> > BR margin, min        : 0%
> > 
> > These give ethtool capability mask of 000,00000600,0000e040, which
> > is:
> > 
> > 	2500baseX (bit 15)
> > 	1000baseX (bit 41)
> > 	10000baseCR (bit 42)
> > 
> > 10000baseCR, 2500baseX and 1000baseX comes from:
> > 
> >         if ((id->base.sfp_ct_passive || id->base.sfp_ct_active) && br_nom) {
> >                 /* This may look odd, but some manufacturers use 12000MBd */
> >                 if (br_min <= 12000 && br_max >= 10300)
> >                         phylink_set(modes, 10000baseCR_Full);
> >                 if (br_min <= 3200 && br_max >= 3100)
> >                         phylink_set(modes, 2500baseX_Full);
> >                 if (br_min <= 1300 && br_max >= 1200)
> >                         phylink_set(modes, 1000baseX_Full);
> > 
> > since id->base.sfp_ct_passive is true, and br_nom = br_max = 10300 and
> > br_min = 0.
> > 
> > 10000baseCR will also come from:
> > 
> >         if (id->base.sfp_ct_passive) {
> >                 if (id->base.passive.sff8431_app_e)
> >                         phylink_set(modes, 10000baseCR_Full);
> >         }
> > 
> > You claimed in your patch description that sfp_ct_passive is not set,
> > but the EEPROM dumps contain:
> > 
> > 	Transceiver type      : Passive Cable
> > 
> > which is correctly parsed by the kernel.
> > 
> > So, I'm rather confused, and I don't see why this patch is needed.
> > 
> 
> Russell,
> 
> something is wrong here, and it is my bad. I hope I didn't mix
> the EEPROM images from when I was playing with the contents, but it
> seems possible now :( I probably sent you modified images and lost the
> original ones.

Ah.

> The thing I know for sure is that it did not work when I got the
> cables and also that they had different contents inside - ie at least
> one side of one cable did not report ct_passive nor ct_active. And I
> think that they reported different things on each side.

One of your files did have a difference in the capabilities - it was
missing the Infiniband capability mentioned above.

> I will try to get another such cable and return to this.

Thanks.

One thing we could do is to augment the "guessing" towards the end of
sfp_parse_support() so that if we encounter a module indicating
support for 10300MBd and 64B/66B, we could set one of the 10G properties
so that at least we get some functionality from modules that report
no capabilities.  See:

        /* If we haven't discovered any modes that this module supports, try
         * the encoding and bitrate to determine supported modes. Some BiDi
         * modules (eg, 1310nm/1550nm) are not 1000BASE-BX compliant due to
         * the differing wavelengths, so do not set any transceiver bits.
         */
        if (bitmap_empty(modes, __ETHTOOL_LINK_MODE_MASK_NBITS)) {
                /* If the encoding and bit rate allows 1000baseX */
                if (id->base.encoding == SFF8024_ENCODING_8B10B && br_nom &&
                    br_min <= 1300 && br_max >= 1200)
                        phylink_set(modes, 1000baseX_Full);
        }

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up

      reply	other threads:[~2020-05-08 18:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-07 13:21 [PATCH net-next] net: sfp: add some quirks for FreeTel direct attach modules Marek Behún
     [not found] ` <CAOJe8K03_BFvfMHOUibi6OZLt28Z8Cn1katyhvJHP5b1rFZbUw@mail.gmail.com>
2020-05-08 15:02   ` Russell King - ARM Linux admin
2020-05-08 15:28 ` Russell King - ARM Linux admin
2020-05-08 16:27   ` Marek Behun
2020-05-08 18:00     ` Russell King - ARM Linux admin [this message]

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=20200508180024.GX1551@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=marek.behun@nic.cz \
    --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;
as well as URLs for NNTP newsgroup(s).