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:

quoted

Hi Russell,

Thanks for your comments,

On Mon, 2021-06-07 at 14:09 +0100, Russell King (Oracle) wrote:

quoted

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:

quoted

Hi Russell,

Thanks for your comments.

On Mon, 2021-06-07 at 10:15 +0100, Russell King (Oracle) wrote:

quoted

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



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