netdev - Re: [v3 2/2] dsa: mv88e6xxx: make serdes SGMII/Fiber output amplitude configurable

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, 8 Dec 2021 18:36:26 +0100
From:   Marek Behún <kabel@...nel.org>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Holger Brunck <holger.brunck@...achienergy.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Jakub Kicinski <kuba@...nel.org>, Andrew Lunn <andrew@...n.ch>
Subject: Re: [v3 2/2] dsa: mv88e6xxx: make serdes SGMII/Fiber output
 amplitude configurable

On Wed, 8 Dec 2021 19:19:09 +0200
Vladimir Oltean <olteanv@...il.com> wrote:

> On Wed, Dec 08, 2021 at 06:00:57PM +0100, Marek Behún wrote:
> > > Also, maybe drop the "serdes-" prefix? The property will sit under a
> > > SERDES lane node, so it would be a bit redundant?  
> > 
> > Hmm. Holger's proposal adds the property into the port node, not SerDes
> > lane node. mv88e6xxx does not define bindings for SerDes lane nodes
> > (yet).  
> 
> We need to be careful about that. You're saying that there chances of
> there being a separate SERDES driver for mv88e6xxx in the future?

I don't think so. Although Russell is working on rewriting the SerDes
code to new Phylink API, the SerDes code will always be a part of
mv88e6xxx driver, I think.

But we already have bindings for internal PHYs on mv88e6xxx, so it
wouldn't be tough to add bindings for SerDeses. The question is whether
this is necessary, since the ports are coupled with their SerDeses in
HW, and the coupling cannot be changed.

But there are models, like 88E6390X, where a SerDes lane is shared
between multiple ports, for example lane 0x12 is shared between port 2
and port 9:
- either the lane can belong to port 2, if port 2 uses serdes
- or the lane can belong to port 9 and port 9 can be in multi-lane mode
  (xaui or rxaui). In this case port 2 uses the internal copper PHY,
  AFAIK

So the question is whether we want to be able to defined this
tx-amplitude different for different lanes. But if so, I think we will
need to add bindings for SerDes PHYs into mv88e6xxx.

So anyway, regarding whether the properites should have a "serdes-"
prefix:
- if they are in SerDes node, it isn't necessary
- if we put them in port nodes, it depends, but probably also is not
  necessary, since I don't think there will ever be a conflict with
  copper TX amplitude or something.

Marek