From patchwork Mon Mar 22 19:50:00 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: 1456835 Return-Path: X-Original-To: incoming-dt@patchwork.ozlabs.org Delivered-To: patchwork-incoming-dt@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org (client-ip=23.128.96.18; helo=vger.kernel.org; envelope-from=devicetree-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=YlNQ4mtr; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by ozlabs.org (Postfix) with ESMTP id 4F44rV06Shz9sWL for ; Tue, 23 Mar 2021 06:51:38 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231695AbhCVTvH (ORCPT ); Mon, 22 Mar 2021 15:51:07 -0400 Received: from mail.kernel.org ([198.145.29.99]:37654 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231636AbhCVTuj (ORCPT ); Mon, 22 Mar 2021 15:50:39 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 3DD6661937; Mon, 22 Mar 2021 19:50:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1616442638; bh=fUkAvUEnpGs/liXmslPmPf6wYjnwcEdyGtAIoM2gdUQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YlNQ4mtrl2LN+G7YQp9FyniCmeDrmLqCQZtZKYz4O9Laloo4TuW8jNQcPGQZA0T3k RNGi9SaecluMKnUVcc76roxuzpXVmoFO20WvthPX9kGuK8bikxugXBBk6TvemAkne6 R01IhpUPg9DVq/v7CinKwv6BzvhQddm/a8kVCoO8tDUOMrftXoTwLvM1RY5G902RhI R5/TiXNTuySQijf3j+GVPPFgMLoF5RPZIBXWkijWGaQEzOfbHcPcJtkwec4JASnQbK RKv93h9p+8kZ2CZQQrGNMnOAdpU1yiZQKOOhMD51SbjY3UVQagYl1rKUJrg1UJqxTw Fn4cp8drzaQiQ== 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:50:00 +0100 Message-Id: <20210322195001.28036-3-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: devicetree@vger.kernel.org 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 + ...