netdev - Re: [PATCH RFC net-next 00/13] Phylink PCS updates

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]

Date:   Wed, 15 Jul 2020 15:31:53 +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 Wed, Jul 15, 2020 at 12:21:01PM +0100, Russell King - ARM Linux admin wrote:
> On Wed, Jul 15, 2020 at 02:46:52AM +0300, Vladimir Oltean wrote:
> > By this I think you are aiming squarely at "[PATCH net-next v3 0/9] net:
> > ethernet backplane support on DPAA1". If I understand you correctly, you
> > are saying that because of the non-phylink models used to represent that
> > system comprised of a clause 49 PCS + clause 72 PMD + clause 73 AN/LT,
> > it is not worth pursuing this phylink-based representation of a clause
> > 37 PCS.
> 
> Actually, that is not what I was aiming that comment at - that is not
> something that has been posted recently.  I'm not going to explicitly
> point at a patch set.
> 

You are making it unnecessarily difficult to have a meaningful
conversation. I'm not going to guess about what patch set you were
talking about. I don't know of anything else that is using the phylib
state machine to drive a PCS than the backplane series. For the PCS
support in Felix/Seville/ENETC (and
drivers/net/ethernet/fman/fman_memac.c by the way), the struct
phy_device is just being used as a container, it is not driven by
phylib.

On Wed, Jul 15, 2020 at 12:34:41PM +0100, Russell King - ARM Linux admin wrote:
> I'm sorry Vladimir, I can't cope with these replies that take hours to
> write to your emails; it just takes up way too much time and interferes
> way too much, I'm going to have to go back to the short sharp replies
> out of necessity or just not reply.
> 
> Sorry.
> 

You know what the problem is here, I'm not given the option to "just not
reply" to you, and you don't seem to like my "short sharp replies"
either.

I'll be frank and state that the big problem I see with phylink is that
there's only one person who can ever be right about it, and that is you,
by definition. I have no mental image about what phylink really is
about, where does it start, where does it end, why does it even exist
and it's not just integrated with phylib. I used to be clear about the
part with SFPs, I'd read the documentation from a few years back when I
was trying to see whether the Lynx PCS is a good fit into phylink, and
it was so centered around MAC ops and a pluggable SFP, that to me, it
was absolutely clear that managing a standalone PCS was not something of
its concern. I would have felt like making "unauthorized modifications"
to it. Managing a standalone PCS could be shoehorned into the existing
ops, and that's exactly what I ended up doing, due to lack of the
greater vision that you have.

Yet, now not only are we talking about adding a standalone PCS layer to
phylink, but also about integrating some functionality which goes deeply
into PMA/PMD territory. I don't necessarily oppose (nor would I have the
power to, as mentioned in my preface), but you can't expect people to
sign up to something that they have no clear idea of what its role is,
not to mention the very volatile API which may not be to everybody's
taste when we're talking about old, stable drivers which support not
only new ARM parts, but also very old PowerPC parts.

The best you came with is that phylink gives you flexibility and
options, and sure it does, when you add a lot of stuff to it to make it
do that. But I don't want to know why phylink is an option, I want to
know why phylib isn't. Phylink is your creation, which as far as I'm
concerned stems out of the need to support more setups than phylib did,
and you took the route of working around phylib rather than extending
it. So, I would have expected an answer from you why phylib is not a
valid place for this.

Regards,
-Vladimir