Date:   Tue, 14 Jul 2020 11:49:58 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Ioana Ciornei <ioana.ciornei@....com>,
        Alexandru Marginean <alexandru.marginean@....com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        "michael@...le.cc" <michael@...le.cc>, netdev@...r.kernel.org,
        Vladimir Oltean <vladimir.oltean@....com>
Subject: Re: [PATCH RFC net-next 00/13] Phylink PCS updates

On Tue, Jun 30, 2020 at 03:27:54PM +0100, Russell King - ARM Linux admin wrote:
> Hi,
> 
> This series updates the rudimentary phylink PCS support with the
> results of the last four months of development of that.  Phylink
> PCS support was initially added back at the end of March, when it
> became clear that the current approach of treating everything at
> the MAC end as being part of the MAC was inadequate.
> 
> However, this rudimentary implementation was fine initially for
> mvneta and similar, but in practice had a fair number of issues,
> particularly when ethtool interfaces were used to change various
> link properties.
> 
> It became apparent that relying on the phylink_config structure for
> the PCS was also bad when it became clear that the same PCS was used
> in DSA drivers as well as in NXPs other offerings, and there was a
> desire to re-use that code.
> 
> It also became apparent that splitting the "configuration" step on
> an interface mode configuration between the MAC and PCS using just
> mac_config() and pcs_config() methods was not sufficient for some
> setups, as the MAC needed to be "taken down" prior to making changes,
> and once all settings were complete, the MAC could only then be
> resumed.
> 
> This series addresses these points, progressing PCS support, and
> has been developed with mvneta and DPAA2 setups, with work on both
> those drivers to prove this approach.  It has been rigorously tested
> with mvneta, as that provides the most flexibility for testing the
> various code paths.
> 
> To solve the phylink_config reuse problem, we introduce a struct
> phylink_pcs, which contains the minimal information necessary, and it
> is intended that this is embedded in the PCS private data structure.
> 
> To solve the interface mode configuration problem, we introduce two
> new MAC methods, mac_prepare() and mac_finish() which wrap the entire
> interface mode configuration only.  This has the additional benefit of
> relieving MAC drivers from working out whether an interface change has
> occurred, and whether they need to do some major work.
> 
> I have not yet updated all the interface documentation for these
> changes yet, that work remains, but this patch set is provided in the
> hope that those working on PCS support in NXP will find this useful.
> 
> Since there is a lot of change here, this is the reason why I strongly
> advise that everyone has converted to the mac_link_up() way of
> configuring the link parameters when the link comes up, rather than
> the old way of using mac_config() - especially as splitting the PCS
> changes how and when phylink calls mac_config(). Although no change
> for existing users is intended, that is something I no longer am able
> to test.
> 
>  drivers/net/phy/phylink.c | 365 +++++++++++++++++++++++++++++++---------------
>  include/linux/phylink.h   | 103 ++++++++++---
>  2 files changed, 337 insertions(+), 131 deletions(-)
> 
> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Are you going to post a non-RFC version?

I think this series makes a lot of sense overall and is a good
consolidation for the type of interfaces that are already established in
Linux.

This changes the landscape of how Linux is dealing with a MAC-side
clause 37 PCS, and should constitute a workable base even for clause 49
PCSs when those use a clause 37 auto-negotiation system (like USXGMII
and its various multi-port variants). Where I have some doubts is a
clause 49 PCS which uses a clause 73 auto-negotiation system, I would
like to understand your vision of how deep phylink is going to go into
the PMD layer, especially where it is not obvious that said layer is
integrated with the MAC.

Thanks,
-Vladimir

Powered by blists - more mailing lists