Message ID | 20210324103556.11338-2-kabel@kernel.org |
---|---|
State | Changes Requested, archived |
Headers | show |
Series | dt-bindings: define property describing supported ethernet PHY modes | expand |
Context | Check | Description |
---|---|---|
robh/checkpatch | success | |
robh/dt-meta-schema | success | |
robh/dtbs-check | fail | build log |
On Wed, Mar 24, 2021 at 11:35:55AM +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). > > 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. Why not just extend phy-connection-type to support more than 1 entry?
On Wed, 24 Mar 2021 14:07:06 -0600 Rob Herring <robh@kernel.org> wrote: > On Wed, Mar 24, 2021 at 11:35:55AM +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). > > > > 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. > > Why not just extend phy-connection-type to support more than 1 entry? Hmm, that would be even better, although it would complicate the Russell's marvell10g patches a little if we want the code to be backward compatible with older device trees. I will look into this. 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> --- .../bindings/net/ethernet-controller.yaml | 89 ++++++++++--------- 1 file changed, 48 insertions(+), 41 deletions(-)