Re: [PATCH net-next v3 03/10] net: sparx5: add hostmode with phylink support

[Steen Hegelund]

Hi Russell,

Thanks for your comments,

On Mon, 2021-06-07 at 16:35 +0100, Russell King (Oracle) wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Mon, Jun 07, 2021 at 05:12:07PM +0200, Steen Hegelund wrote:
> > Hi Russell,
> > 
> > Thanks for your comments,
> > 
> > On Mon, 2021-06-07 at 14:09 +0100, Russell King (Oracle) wrote:
> > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > > 
> > > On Mon, Jun 07, 2021 at 02:45:01PM +0200, Steen Hegelund wrote:
> > > > Hi Russell,
> > > > 
> > > > Thanks for your comments.
> > > > 
> > > > On Mon, 2021-06-07 at 10:15 +0100, Russell King (Oracle) wrote:
> > > > > 3) I really don't get what's going on with setting the port mode to
> > > > >    2500base-X and 1000base-X here when state->interface is 10GBASER.
> > > > 
> > > > The high speed interfaces (> 2.5G) do not support any in-band signalling, so the only way
> > > > that
> > > > e.g a
> > > > 10G interface running at 2.5G will be able to link up with its partner is if both ends
> > > > configure
> > > > the
> > > > speed manually via ethtool.
> > > 
> > > We really should not have drivers hacking around in this way. If we want
> > > to operate in 2500base-x or 1000base-x, then that is what phylink should
> > > be telling the MAC driver. The MAC driver should not be making these
> > > decisions in its mac_config() callback. Doing so makes a joke of kernel
> > > programming.
> > 
> > I have this scenario where two Sparx5 Devices are connected via a 25G DAC cable.
> > Sparx5 Device A has the cable connected to one of its 25G Serdes devices, but Sparx5 Device B
> > has
> > the cable connected to one of its 10G Serdes devices.
> > 
> > By default the Sparx5 A device will configure the link to use a speed of 25G, but the Sparx5
> > device
> > B will configure the link speed to 10G, so the link will remain down, as the two devices cannot
> > communicate.
> > 
> > So to fix this the user will have to manually change the speed of the link on Device A to be 10G
> > using ethtool.
> > 
> > I may have misunderstood the usage of the mac_config callback, but then where would the driver
> > then
> > use the speed information from the user to configure the Serdes?
> 
> How is this any different to the situation that we have on SolidRun
> Clearfog platforms and the Macchiatobin where we have a SFP port
> capable of 2500base-X and 1000base-X. If we plug in a 4.3Gbps
> fiberchannel SFP, the port is able to run at either of those speeds.
> 
> We can control this via ethtool, changing between the two modes by
> either forcing the speed to either 1000 or 2500, or switching the
> "advertisement" between 1000base-X or 2500base-X - we enforce that
> only one of these can be advertised at any one time. The switching
> between them happens in the ->validate callback, but that may change
> in the future (especially as there has been a report that making
> this decision in ->validate causes some issues in a particular usage
> scenarios.) It seems we need to solve that basic issue first, and
> then expand it to cater for the case you have.
> 
> Phylink expects that the *_config and link_up callbacks are a "do
> what I say" setup; they don't expect MAC or PCS drivers to start
> making their own decisions at that point - because then the state
> known to phylink and the actual hardware setup then differ.

I will change the implementation to use the PCS operations, add the 25GBASER value and avoid making
any phy_interface_t mode changes in the config function.

But it looks like there is a general need for adjusting the phy_interface_t value (and the mode
bits) based on ethtool input like speed (similar to what the phylink_helper_basex_speed function
does), also for the nBASER case, so that would be a useful addition to phylink, to support some of
the usecases we have.

Should I add the phylink_helper_basex_speed call to the implementation now?

> 
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!


-- 
BR
Steen

-=-=-=-=-=-=-=-=-=-=-=-=-=-=
steen.hegelund@xxxxxxxxxxxxx