netdev - Re: [PATCH RFC russell-king 3/4] net: phy: marvell10g: change MACTYPE according to phydev->interface

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: <20200812182817.1bb7bb4a@dellmb.labs.office.nic.cz>
Date:   Wed, 12 Aug 2020 18:28:17 +0200
From:   Marek Behún <marek.behun@....cz>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Maxime Chevallier <maxime.chevallier@...tlin.com>,
        Baruch Siach <baruch@...s.co.il>,
        Chris Healy <cphealy@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>, netdev@...r.kernel.org
Subject: Re: [PATCH RFC russell-king 3/4] net: phy: marvell10g: change
 MACTYPE according to phydev->interface

On Wed, 12 Aug 2020 17:22:32 +0100
Russell King - ARM Linux admin <linux@...linux.org.uk> wrote:

> On Wed, Aug 12, 2020 at 06:13:33PM +0200, Marek Behún wrote:
> > The MACTYPE is not being lost. But changing it requires Port
> > Software Reset, which resets the link, so it cannot be done for
> > example in read_status.  
> 
> Wouldn't the right place to configure it be in the config_init()
> method - which is called once we have a MAC attaching to the PHY?
> As I mentioned, if we had a way to pass the MAC interface supported
> mask into phylib, config_init() could then use that to determine what
> to do.
> 

It is done from config_init. mv3310_power_up is called from
mv3310_config_init.

> > I think the MACTYPE should be set sometime during PHY
> > initialisation, and only once: either to XFI with rate matching, if
> > the underlying MAC does not support lower modes, or to
> > 10gbase-r/2500base-x/sgmii mode, if the underlying MAC supports
> > only slower modes than 10G.  
> 
> Yes - only changing the MAC type if we have good reason to do so to
> support other rates.
> 
> There is a related problem however.  Note that if you have an 88x3310
> (non-P) in the SFP, then when rate matching is enabled, the PHY will
> _not_ generate pause frames, and the PHY expects the MAC to be
> configured to pace itself to the slower speed.  I don't believe we
> have support in MACs for that, but phylib and therefore phylink
> provides the information:
> 
> 	interface - 10GBASE-R
> 	speed - media speed
> 	pause - media pause modes
> 
> So, if speed != SPEED_10000 and there are no pause modes, we should,
> for the sake of the entire link, pace the MAC to the media speed by
> controlling its egress rate.
>