From patchwork Mon Mar 22 19:49:58 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Marek_Beh=C3=BAn?= X-Patchwork-Id: 12155997 X-Patchwork-Delegate: kuba@kernel.org Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 23E29C433E1 for ; Mon, 22 Mar 2021 19:51:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D6F8F61934 for ; Mon, 22 Mar 2021 19:51:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231764AbhCVTvI (ORCPT ); Mon, 22 Mar 2021 15:51:08 -0400 Received: from mail.kernel.org ([198.145.29.99]:37560 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230358AbhCVTuf (ORCPT ); Mon, 22 Mar 2021 15:50:35 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 3ECBD61934; Mon, 22 Mar 2021 19:50:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1616442634; bh=fUkAvUEnpGs/liXmslPmPf6wYjnwcEdyGtAIoM2gdUQ=; h=From:To:Cc:Subject:Date:From; b=rL1dolayHEwYBnzrtQL4Cu6iuawqzTyvCsH5KqarIVAkOR9WI6GN93GzOwof4GNIc aJcQjHEX/0jZqwvqvdGprc9Cxef9EGW5Hd++mGkv4VvFM3c4bM1cUTwii64/GyGise 7vBauPjxuX8Kuun5WLfQeS404EKcAngsnmrkL6DqJZNoXrWWj7RMBfcZtv5awtqpGj XzJQ6CHzNtxxMaLKI2FWGZSspDq8EZMX/go3crIE/sxje1inHf7oRRxZ8VUlJWbW/3 fxpqZzxdiHOGw63nPK5zCyVB3MiSb0Gd/0WtvhX5di6VaLo7Mo/rTOw4Mp7PV6428f YHTUuzF9Bnc/g== From: =?utf-8?q?Marek_Beh=C3=BAn?= To: netdev@vger.kernel.org, Andrew Lunn , "David S . Miller" , Florian Fainelli , Heiner Kallweit , Russell King , Rob Herring , devicetree@vger.kernel.org Cc: =?utf-8?q?Marek_Beh=C3=BAn?= Subject: [RFC net-next 1/2] dt-bindings: ethernet-controller: create a type for PHY interface modes Date: Mon, 22 Mar 2021 20:49:58 +0100 Message-Id: <20210322195001.28036-1-kabel@kernel.org> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: kuba@kernel.org X-Patchwork-State: RFC 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 --- 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(-) 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 + ... From patchwork Mon Mar 22 19:49:59 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Marek_Beh=C3=BAn?= X-Patchwork-Id: 12155999 X-Patchwork-Delegate: kuba@kernel.org Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3F85DC433E5 for ; Mon, 22 Mar 2021 19:51:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 167E1619B5 for ; Mon, 22 Mar 2021 19:51:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232090AbhCVTvO (ORCPT ); Mon, 22 Mar 2021 15:51:14 -0400 Received: from mail.kernel.org ([198.145.29.99]:37596 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231621AbhCVTuh (ORCPT ); Mon, 22 Mar 2021 15:50:37 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 3EF326198E; Mon, 22 Mar 2021 19:50:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1616442636; bh=itcODGQHLpuXMXSmPfGYKFBLRHdM96wzv6qnbYt2C+E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=R4F0kf64zmG4qTDSfQ+kPWCy4LRHTC3JUOesC1X23302nYEPd+4EWodurVWz2RLJb vcr18b+QoJ35q21jq5dommhmFOmpfOhPXkPLgZ7LscClagKKkh7X87pW+M9CZN8fZq 0wxTsprFpb7kZvnjmL/1abvdEXDgApQi7aT6cv5TF7HTQLt+s+3xnwwcSPt0jk1aH1 eU2bJD6t5xXe80rZZA54p5heeGfy7yOUNCDmjA6ig6CQ3tshh6tac5GfsjFIopvZYx i4y46tQUdrtR3wKFXVtfMgRDPDU+/9OeuRDrSLvTptFnbKVruF505Zskd+oQjVGTaB uY7F799+Ek1Mg== From: =?utf-8?q?Marek_Beh=C3=BAn?= To: netdev@vger.kernel.org, Andrew Lunn , "David S . Miller" , Florian Fainelli , Heiner Kallweit , Russell King , Rob Herring , devicetree@vger.kernel.org Cc: =?utf-8?q?Marek_Beh=C3=BAn?= Subject: [RFC net-next 2/2] dt-bindings: ethernet-phy: define `unsupported-mac-connection-types` property Date: Mon, 22 Mar 2021 20:49:59 +0100 Message-Id: <20210322195001.28036-2-kabel@kernel.org> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20210322195001.28036-1-kabel@kernel.org> References: <20210322195001.28036-1-kabel@kernel.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: kuba@kernel.org X-Patchwork-State: RFC An ethernet PHY may support PHY interface modes that are not wired on a specific board (or are broken for some other reason). In order for the kernel to know that these modes should not be used, we need to specify this in device tree. Define a new ethernet PHY property `unsupported-mac-connection-types`, which lists these unsupported modes. Signed-off-by: Marek Behún --- As in the previous patch: we allow both `phy-connection-type` and `phy-mode` to define PHY interface mode. Should we call this new property as it is proposed by this patch, or something different, like `unsupported-mac-phy-modes`? Also, some PHYs (marvell10g for example) also multiple units (host unit for connecting to the MAC, fiber unit for connecting for example via a SFP). Should we also add `unsupported-fiber-connection-types` property? Moreover should this property be a member of PHY's node, or the ethernet controller's node? Were it a member of ethernet controller's node, we wouldn't need to $ref a definition from another file's $defs (which Rob Herring says that so far is done only in withing single file). On the other hand `unsupported-fiber-connection-types` property should be a member of PHY's node, if we will add this in the future. --- .../devicetree/bindings/net/ethernet-phy.yaml | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml index 2766fe45bb98..4c5b8fabbec3 100644 --- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml @@ -136,6 +136,20 @@ properties: used. The absence of this property indicates the muxers should be configured so that the external PHY is used. + unsupported-mac-connection-types: + $ref: "ethernet-controller.yaml#/$defs/phy-connection-type-array" + description: + The PHY device may support different interface types for + connecting the Ethernet MAC device to the PHY device (i.e. + rgmii, sgmii, xaui, ...), but not all of these interface + types must necessarily be supported for a specific board + (either not all of them are wired, or there is a known bug + for a specific mode). + This property specifies a list of interface modes are not + supported on the board. + minItems: 1 + maxItems: 128 + resets: maxItems: 1 @@ -196,5 +210,6 @@ examples: reset-gpios = <&gpio1 4 1>; reset-assert-us = <1000>; reset-deassert-us = <2000>; + unsupported-mac-connection-types = "xaui", "rxaui"; }; };