Messages in this thread | | | Subject | Re: [PATCH net-next v3 03/10] net: sparx5: add hostmode with phylink support | From | Steen Hegelund <> | Date | Tue, 8 Jun 2021 11:24:46 +0200 |
| |
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@microchip.com
| |