On Mon, 22 Mar 2021 22:11:04 +0100 Andrew Lunn <andrew@xxxxxxx> wrote: > On Mon, Mar 22, 2021 at 08:49:58PM +0100, Marek Behún wrote: > > In order to be able to define a property describing an array of PHY > > interface modes, we need to change the current scalar > > `phy-connection-type`, which lists the possible PHY interface modes, to > > an array of length 1 (otherwise we would need to define the same list at > > two different places). > > Hi Marek > > Please could you include a 0/2 patch which explains the big > picture. It is not clear to me why you need these properties. What is > the problem you are trying to solve? That should be in the patch > series cover note. > > Andrew Hi Andrew, sorry, I did not add a cover letter because the second patch commit message basically explains the purpose, but now I realize that a cover letter could mention a specific example. I will include a cover letter in v2. Meanwhile I can explain the purpose here: Some PHYs support interface modes that must not necessarily be wired on a board. A good example is Marvell 88x3310 PHY, which supports several modes via one SerDes lane (10gbase-r, usxgmii, 5gbase-r, 2500base-x, sgmii), but also via 2 or 4 SerDes lanes (rxaui and xaui). So a board utilizing this PHY can have different constraints: - the board wiring can have a frequnecy constraint (for example the connection can go via a connector that does not support frequencies greater than 6 GHz, so for 10g link multiple lanse - xaui or rxaui - must be used) - the board may simply not wire all SerDes lanes - the MAC does not have to support all these modes For the first two points it is impossible for the code to know this without it being specified in device tree. The last one can be solved in code, and Russell King has experimental patches in his repo for this (both MAC and PHY driver fill up a supported_interfaces bitmask). But why can't we just depend on the phy-mode property defined in ethernet controller's OF node? Becuase this PHY can change its interface mode to the MAC depending on the negotiated speed on the copper side. This PHY has several possible configurations - communicate with the MAC in USXGMII. This is simplest one since the interface mode does not change even if copper speed changes - 10gbase-r/5gbase-r/2500base-x/sgmii depending on the copper speed - xaui/5gbase-r/2500base-x/sgmii depending on the copper speed - rxaui/5gbase-r/2500base-x/sgmii depending on the copper speed - 10gbase-r with rate matching - xaui with rate matching - rxaui with rate matching One of these configurations is selected by strapping pins, and can be read by the marvell10g driver. The driver can then change phy-mode on the MAC side. One problem is that the mode selected by the strapping pins may not be ideal. There are some erratas published for this PHY, which say that rate-matching is broken in some conditions (speed <= 1000), for example. Also the rate-matching mode is not optimal if the MAC supports the lower-speed modes, because of overhead of sending pause-frames. So in order to select the best possible configuration, we need to know which PHY interface modes are supported on the board. The most generic solution is to specify a property which either lists unsupported PHY modes or supported PHY modes (if missing, assume all modes are supported). Marek
