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