[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210112224408.2282ce5e@kernel.org>
Date: Tue, 12 Jan 2021 22:44:08 +0100
From: Marek BehĂșn <kabel@...nel.org>
To: Vladimir Oltean <olteanv@...il.com>
Cc: netdev@...r.kernel.org, pavana.sharma@...i.com,
vivien.didelot@...il.com, f.fainelli@...il.com, kuba@...nel.org,
lkp@...el.com, davem@...emloft.net, ashkan.boldaji@...i.com,
andrew@...n.ch, Chris Packham <chris.packham@...iedtelesis.co.nz>,
Russell King - ARM Linux admin <linux@...linux.org.uk>
Subject: Re: [PATCH net-next v15 5/6] net: dsa: mv88e6xxx: Add support for
mv88e6393x family of Marvell
On Tue, 12 Jan 2021 23:30:48 +0200
Vladimir Oltean <olteanv@...il.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@...il.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
Powered by blists - more mailing lists