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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 7 Jun 2021 16:35:22 +0100
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Steen Hegelund <steen.hegelund@...rochip.com>
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

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.

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