Re: [PATCH net-next v15 5/6] net: dsa: mv88e6xxx: Add support for mv88e6393x family of Marvell

["Marek Behún" <kabel@kernel.org>]

On Tue, 12 Jan 2021 23:30:48 +0200
Vladimir Oltean <olteanv@gmail.com> wrote:

> On Tue, Jan 12, 2021 at 10:16:32PM +0100, Marek Behún wrote:
> > On Tue, 12 Jan 2021 22:38:08 +0200
> > Vladimir Oltean <olteanv@gmail.com> wrote:
> >   
> > > > +		phylink_set(mask, 10000baseT_Full);
> > > > +		phylink_set(mask, 10000baseCR_Full);
> > > > +		phylink_set(mask, 10000baseSR_Full);
> > > > +		phylink_set(mask, 10000baseLR_Full);
> > > > +		phylink_set(mask, 10000baseLRM_Full);
> > > > +		phylink_set(mask, 10000baseER_Full);  
> > > 
> > > Why did you remove 1000baseKR_Full from here?  
> > 
> > I am confused now. Should 1000baseKR_Full be here? 10g-kr is 10g-r with
> > clause 73 autonegotiation, so they are not compatible, or are they?  
> 
> ETHTOOL_LINK_MODE_10000baseKR_Full_BIT and most of everything else from
> enum ethtool_link_mode_bit_indices are network-side media interfaces
> (aka between the PHY and the link partner).
> 
> Whereas PHY_INTERFACE_MODE_10GKR and most of everything else from
> phy_interface_t is a system-side media independent interface (aka
> between the MAC and the PHY).

OK that finaly clears things up :) Sorry, I misunderstood it: I thought
that PHY_INTERFACE_MODE_10GKR is related to 10000baseKR_Full and that
they are incompatible with 10gbase-r.

> What the 6393X does not support is PHY_INTERFACE_MODE_10GKR, and my
> feedback from your previous series did not ask you to remove
> 1000baseKR_Full from phylink_validate. There's nothing that would
> prevent somebody from attaching a PHY with a different (and compatible)
> system-side SERDES protocol, and 10GBase-KR on the media side.
> 
> What Russell said is that he's seriously thinking about reworking the
> phylink_validate API so that the MAC driver would not need to sign off
> on things it does not care about (such as what media-side interface will
> the PHY use, of which there is an ever increasing plethora). But at the
> moment, the API is what it is, and you should put as many media-side
> link modes as possible, at the given speed and duplex that the MAC
> supports.
> 
> _I_ am confused. What did you say you were happy to help with?

I am happy to help with phylink_validate code refactorization -
refactorization of the code itself, reviewing, testing.

Marek