Re: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS)

From: "Pali Rohár" <pali@kernel.org>
To: Giammarco lynx <stich86@gmail.com>
Cc: "Russell King (Oracle)" <linux@armlinux.org.uk>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS)
Date: Mon, 9 May 2022 13:24:35 +0200	[thread overview]
Message-ID: <20220509112435.t6ks33pahm5rpkwh@pali> (raw)
In-Reply-To: <CAJbjdrSAmi3uBXK0sqKJZT-RFn_pXD2jUJiGp7_4ZAVDRBeTyw@mail.gmail.com>

On Monday 09 May 2022 13:13:04 Giammarco lynx wrote:
> Hi Pali,
> 
> no, the stick can do 2.5GbE. Both RTL9601CI and RTL 9601D support
> HiSGMII mode.

Hello! That is really interesting, because I was told that RTL8672 and
RTL9601C support only 1000base-x.

Maybe RTL9601CI and RTL9601D chips are new version with support for
2500base-x? I have no idea.

Anyway, if you have some datasheet or source of information that it
supports 2500base-x mode, I would really like to see it.

> I’m currently running another stick (DFP-34X-C2C) at
> 2.5GbE with my FTTH line here in Italy :)
> 
> the problem seems related only to SFP driver of macchiato-bin, into a
> BCM57810s, the stick is working as expected ;)
> 
> Il giorno dom 8 mag 2022 alle ore 18:31 Pali Rohár <pali@kernel.org> ha scritto:
> >
> > Hello!
> >
> > On Monday 07 March 2022 23:01:18 Russell King (Oracle) wrote:
> > > > > [   86.013661] sfp sfp-eth3: Detected broken RTL8672/RTL9601C emulated EEPROM
> > > > > [   86.020569] sfp sfp-eth3: Switching to reading EEPROM to one byte at a time
> > > > > [   86.067758] sfp sfp-eth3: module OEM              V2801F
> > > > > rev 1.0  sn 202101195032     dc 210119
> > > > > [   86.077555] mvpp2 f4000000.ethernet eth3: requesting link mode
> > > > > inband/1000base-x with support 0000000,00000200,00000440
> > > > > [   86.088390] sfp sfp-eth3: tx disable 1 -> 0
> > >
> > > We've now detected what the module is, and we configure for it, which
> > > the EEPROM indicates it supports 1200Mbaud, which is 1G speed.
> > ...
> > > > > In that way it goes up. So how can we avoid this behaviour?
> > >
> > > Very difficult to avoid it. My guess is that when you power up the
> > > system with the module inserted, it sees the interface operating at
> > > 2.5G speed and locks itself to 2.5G speed.
> > >
> > > Eventually, our kernel boots, and sfp reads the EEPROM. The EEPROM
> > > indicates that it supports 1G speed, so we switch the host interface
> > > to 1000base-X, and that causes link to be lost (although I don't see
> > > any sign of that happening in your debug.)
> > >
> > > That means that the module has decided to use 2.5G speed, but its
> > > reporting it supports 1G speed in the EEPROM... so its doing something
> > > different. No surprises that the link fails to come up.
> > >
> > > We could add an entry to the sfp_quirks[] table in sfp-bus.c for this
> > > module using the sfp_quirk_2500basex function to also indicate it
> > > supports 2.5G speed:
> > >
> > >       }, {
> > >               // VSOL/CarlitoxxPro SFP can also work at 2.5G speed
> > >               .part = "V2801F",
> > >               .modes = sfp_quirk_2500basex,
> >
> > RTL8672/RTL9601C chips support only 1000base-x mode and therefore SFP
> > cannot operate on CPU side at 2500base-x nor in other way at 2.5G.
> >
> > Trying to "force" mode to 2500base-x would not work.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel