netdev - Re: [PATCH net-next v2 4/8] net: phylink: update supported

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:   Thu, 2 Dec 2021 23:25:50 +0100
From:   Marek Behún <kabel@...nel.org>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     "Russell King (Oracle)" <linux@...linux.org.uk>,
        netdev@...r.kernel.org, Andrew Lunn <andrew@...n.ch>,
        Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
        Jakub Kicinski <kuba@...nel.org>,
        Sean Anderson <sean.anderson@...o.com>, davem@...emloft.net
Subject: Re: [PATCH net-next v2 4/8] net: phylink: update
 supported_interfaces with modes from fwnode

On Wed, 24 Nov 2021 14:31:35 +0200
Vladimir Oltean <olteanv@...il.com> wrote:

> > > To err is human, of course. But one thing I think we learned from the
> > > old implementation of phylink_validate is that it gets very tiring to
> > > keep adding PHY modes, and we always seem to miss some. When that array
> > > will be described in DT, it could be just a tad more painful to maintain.  
> > 
> > The thing is that we will still need the `phy-mode` property, it can't
> > be deprecated IMO.  
> 
> Wait a minute, who said anything about deprecating it? I just said
> "let's not make it an array, in the actual device tree". The phy-mode
> was, and will remain, the initial MII-side protocol, which can or cannot
> be changed at runtime.

Hello Vladimir,

I was told multiple times that device-tree should not specify how the
software should behave (given multiple HW options). This has not been
always followed, but it is preferred.

Now the 'phy-mode' property, if interpreted as "the initial MII-side
protocol" would break this rule.

This is therefore another reason why it should either be extended to an
array, or, if we went with your proposal of 'num-lanes' + 'max-freq',
deprecated (at least for serdes modes). But it can't be deprecated
entirely, IMO (because of non serdes protocols).

I thought more about your proposal of 'num-lanes' + 'max-freq' vs
extending 'phy-mode'.

- 'num-lanes' + 'max-freq' are IMO closer to the idea of device-tree,
  since they describe exactly how the parts of the device are connected
  to each other
- otherwise I think your argument against extending 'phy-mode' because
  of people declaring support for modes that weren't properly tested and
  would later be found broken is invalid, since the same could happen
  for 'num-lanes' + 'max-freq' properties
- the 'phy-mode' property already exists. I think if we went with the
  'num-lanes' + 'max-freq' proposal, we would need to deprecate
  'phy-mode' for serdes protocols (at least for situations where
  multiple modes can be used, since then 'phy-mode' would go against
  the idea of the rule I mentioned in first paragraph)

Vladimir, Rob has now given R-B for the 'phy-mode' extension patch.

I am wondering now what to do, since other people haven't given their
opinions here. Whether to re-send the series, and maybe start discussing
there, or waiting more.

Marek