Re: [PATCH net-next v2 4/8] net: phylink: update supported_interfaces with modes from fwnode

["Marek Behún" <kabel@kernel.org>]

On Wed, 24 Nov 2021 14:31:35 +0200
Vladimir Oltean <olteanv@gmail.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