netdev - Re: [PATCH net-next v3 5/9] net: dsa: add support for phylink_pcs

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:   Mon, 22 Jun 2020 15:07:28 +0100
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Ioana Ciornei <ioana.ciornei@....com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        Vladimir Oltean <vladimir.oltean@....com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Alexandru Marginean <alexandru.marginean@....com>,
        "michael@...le.cc" <michael@...le.cc>,
        "andrew@...n.ch" <andrew@...n.ch>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "olteanv@...il.com" <olteanv@...il.com>
Subject: Re: [PATCH net-next v3 5/9] net: dsa: add support for phylink_pcs_ops

On Mon, Jun 22, 2020 at 01:51:55PM +0000, Ioana Ciornei wrote:
> > Right, but we're talking about hardware that is common not only in DSA but
> > elsewhere - and we already deal with that outside of DSA with PHYs.
> 
> I said before why the PHY use case is different from a PCS tightly
> coupled inside the SoC.

Yes, however, I'm responding to your point about whether DSA maintainers
would be happy with it, so I've used the already existing example with
phylib to illustrate that this already happens in DSA-land.  I was not
meaning to refer to your point about the PCS being tightly coupled
inside the SoC.  That should've been clear by the comment immediately
below:

> > So, what I'm proposing is really nothing new for DSA.


> > Do you know what those errata would be?  I'm only aware of A-011118 in the
> > LX2160A which I don't believe will impact this code.  I don't have visibility of
> > Ocelot/Felix.
> 
> I was mainly looking at this from a software architecture perspective,
> not having any explicit erratum in mind.

Ok.

> > > On the other hand, I am not sure what is the concrete benefit of doing
> > > it your way. I understand that for a PHY device the MAC is not
> > > involved in the call path but in the case of the PCS the expectation
> > > is that it's tightly coupled in the silicon and not plug-and-play.
> > 
> > The advantage is less lines of code to maintain, and a more efficient and
> > understandable code structure.  I would much rather start off simple and then
> > augment rather than start off with unnecessary complexity and then get stuck
> > with it while not really needing it.
> > 
> 
> I am not going to argue ad infinitum on this. If you think keeping the
> phylink_pcs_ops structure outside is the better approach then let's
> take that route.
> 
> I will go through your feedback on the actual Lynx module and respond/make the
> necessary adjustments.
> 
> Beside this, what should be our next move? Will you submit the new method of
> working with the phylink_pcs_ops structure?

I do think it is the best approach _at the moment_ given what we know
at this time - without over-designing for situations that we don't know.

So, I'll take this as tentative agreement, and I'll begin work on
converting my local users, testing, and then sending a finished
patch.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!