Thread (20 messages) 20 messages, 4 authors, 2021-12-04

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

From: Marek Behún <kabel@kernel.org>
Date: 2021-12-02 22:26:00
Also in: netdev

On Wed, 24 Nov 2021 14:31:35 +0200
Vladimir Oltean [off-list ref] wrote:
quoted
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help