Message-ID: <f9b254936d21ea1cc13f174525a97847378afef4.camel@microchip.com>
Date:   Tue, 8 Jun 2021 11:24:46 +0200
From:   Steen Hegelund <steen.hegelund@...rochip.com>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
CC:     "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, Andrew Lunn <andrew@...n.ch>,
        Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Madalin Bucur <madalin.bucur@....nxp.com>,
        Mark Einon <mark.einon@...il.com>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        "Simon Horman" <simon.horman@...ronome.com>,
        <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        Bjarni Jonasson <bjarni.jonasson@...rochip.com>,
        Lars Povlsen <lars.povlsen@...rochip.com>
Subject: Re: [PATCH net-next v3 03/10] net: sparx5: add hostmode with
 phylink support

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@...rochip.com

Powered by blists - more mailing lists