[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 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?

> 
> --
> 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 at microchip.com