| Message ID | 20210322195001.28036-1-kabel@kernel.org (mailing list archive) |
|---|---|
| State | RFC |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [RFC,net-next,1/2] dt-bindings: ethernet-controller: create a type for PHY interface modes | expand |
| Context | Check | Description |
|---|---|---|
| netdev/cover_letter | success | Link |
| netdev/fixes_present | success | Link |
| netdev/patch_count | success | Link |
| netdev/tree_selection | success | Clearly marked for net-next |
| netdev/subject_prefix | success | Link |
| netdev/cc_maintainers | warning | 2 maintainers not CCed: robh+dt@kernel.org kuba@kernel.org |
| netdev/source_inline | success | Was 0 now: 0 |
| netdev/verify_signedoff | success | Link |
| netdev/module_param | success | Was 0 now: 0 |
| netdev/build_32bit | success | Errors and warnings before: 0 this patch: 0 |
| netdev/kdoc | success | Errors and warnings before: 0 this patch: 0 |
| netdev/verify_fixes | success | Link |
| netdev/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 102 lines checked |
| netdev/build_allmodconfig_warn | success | Errors and warnings before: 0 this patch: 0 |
| netdev/header_inline | success | Link |
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
On Mon, 22 Mar 2021 22:11:04 +0100 Andrew Lunn <andrew@lunn.ch> 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
diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml index 4b7d1e5d003c..0ee25ecbffde 100644 --- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml @@ -53,50 +53,12 @@ properties: const: mac-address phy-connection-type: + $ref: "#/$defs/phy-connection-type-array" description: Specifies interface type between the Ethernet device and a physical layer (PHY) device. - enum: - # There is not a standard bus between the MAC and the PHY, - # something proprietary is being used to embed the PHY in the - # MAC. - - internal - - mii - - gmii - - sgmii - - qsgmii - - tbi - - rev-mii - - rmii - - # RX and TX delays are added by the MAC when required - - rgmii - - # RGMII with internal RX and TX delays provided by the PHY, - # the MAC should not add the RX or TX delays in this case - - rgmii-id - - # RGMII with internal RX delay provided by the PHY, the MAC - # should not add an RX delay in this case - - rgmii-rxid - - # RGMII with internal TX delay provided by the PHY, the MAC - # should not add an TX delay in this case - - rgmii-txid - - rtbi - - smii - - xgmii - - trgmii - - 1000base-x - - 2500base-x - - 5gbase-r - - rxaui - - xaui - - # 10GBASE-KR, XFI, SFI - - 10gbase-kr - - usxgmii - - 10gbase-r + minItems: 1 + maxItems: 1 phy-mode: $ref: "#/properties/phy-connection-type" @@ -226,4 +188,49 @@ properties: additionalProperties: true +'$defs': + phy-connection-type-array: + items: + enum: + # There is not a standard bus between the MAC and the PHY, + # something proprietary is being used to embed the PHY in the + # MAC. + - internal + - mii + - gmii + - sgmii + - qsgmii + - tbi + - rev-mii + - rmii + + # RX and TX delays are added by the MAC when required + - rgmii + + # RGMII with internal RX and TX delays provided by the PHY, + # the MAC should not add the RX or TX delays in this case + - rgmii-id + + # RGMII with internal RX delay provided by the PHY, the MAC + # should not add an RX delay in this case + - rgmii-rxid + + # RGMII with internal TX delay provided by the PHY, the MAC + # should not add an TX delay in this case + - rgmii-txid + - rtbi + - smii + - xgmii + - trgmii + - 1000base-x + - 2500base-x + - 5gbase-r + - rxaui + - xaui + + # 10GBASE-KR, XFI, SFI + - 10gbase-kr + - usxgmii + - 10gbase-r + ...
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). Moreover Rob Herring says that we cannot reuse the values of a property; we need to $ref a type. Move the definition of possible PHY interface modes from the `phy-connection-type` property to an array type definition `phy-connection-type-array`, and simply reference this type in the original property. Signed-off-by: Marek Behún <kabel@kernel.org> --- Is `phy-connection-type` prefered over `phy-mode`? If not, maybe the type could be called `phy-modes-array`... --- .../bindings/net/ethernet-controller.yaml | 89 ++++++++++--------- 1 file changed, 48 insertions(+), 41 deletions(-)