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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

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