From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 29ACCC43334 for ; Tue, 12 Jul 2022 19:38:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=OdKwsuJzGft3CRvuWZT8555hOkw5ETxAMKbsGD2siJU=; b=ERaxQ0tJjbIyg1 LqLVWZRW75om6M51y3tlP4+BMPGlYnlxI9Ey5hd7EGILgdGRffxqg3v92X7qDj+XFzysxmR4/MTzK nZ3jN2fKE0lSOtjOcGjVQUQZ/rjm/Icko88Ar4qSWHMhU1bEvOgs5Hj2DmZUrNT0/yMrCzET+YVRL HW/JHvg9ow6g7WPtVW/saxuJhSo3VDzXbEvVq89xIZDcq4KEu6Jt3rDsNsBsKqy7PTDSlu++PtGs7 ezyCQxp2DGODhXaZNAA7Y8WKyq/6Hhr4BLpJlGUfsSIFg5x5cfeu9wJzjjdlPcj3eCa/GITND6AOd wmIquWVm5RSzYO3DkYqg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oBLgu-00EE27-NA; Tue, 12 Jul 2022 19:37:04 +0000 Received: from mail-io1-f53.google.com ([209.85.166.53]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oBLgr-00EE0X-B9 for linux-arm-kernel@lists.infradead.org; Tue, 12 Jul 2022 19:37:03 +0000 Received: by mail-io1-f53.google.com with SMTP id e5so8893421iof.2 for ; Tue, 12 Jul 2022 12:36:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=FCz9giN1y8D5RRiEJxyyLtO77K8fLr29mBbOuViLcRQ=; b=W6Rp65o7ibyUXN0SddivlPulgSk+6EpYsxcLOvXkUU/R4Te+pQqxzjSzgE9iWlnJcC sLI+wM4wffoZQ8/Z/owHQcsQfdIHWnsBd0zll1SP5pZlZkZZGJ7Rkede+pqQjhHThKDi CuRLpMZDOCbWNYrtBnOGEMvcro9aBxAEBkty19qHgEZffpDpOcMEddWP/2V7A1dORKH2 9BTFD52Is/v8v5txkxNT/hOppShf5RhEzyd2iFHddKb3msS1Hd2FVXv8BVGJJo+FKQV+ D8fIUBUHHP89DScjsQ+fW/FgyojOEQKnPotBjAWTjhuyvDrD8c+HEc962e8FIChqRn8L 7LNA== X-Gm-Message-State: AJIora9xWX05UyzABmDUqILb2fmqjVx80iDyWjNRfZY1ELQ5xuX+tVwq PFozAj2ht0X5LezWxfL2rQ== X-Google-Smtp-Source: AGRyM1vadDEy7jk0/x/ZutR1thOuPrFfdoKFa0KdUYoX8sbTqqYQvnInt9StfljBWfdfaXfcafRpkA== X-Received: by 2002:a05:6638:1406:b0:33f:5eae:a52d with SMTP id k6-20020a056638140600b0033f5eaea52dmr5225907jad.243.1657654614343; Tue, 12 Jul 2022 12:36:54 -0700 (PDT) Received: from robh.at.kernel.org ([64.188.179.248]) by smtp.gmail.com with ESMTPSA id w3-20020a02b0c3000000b0033f3dd2e7e7sm4397870jah.44.2022.07.12.12.36.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Jul 2022 12:36:53 -0700 (PDT) Received: (nullmailer pid 2238514 invoked by uid 1000); Tue, 12 Jul 2022 19:36:51 -0000 Date: Tue, 12 Jul 2022 13:36:51 -0600 From: Rob Herring To: Sean Anderson Cc: "David S . Miller" , Jakub Kicinski , Madalin Bucur , netdev@vger.kernel.org, Russell King , Paolo Abeni , linux-arm-kernel@lists.infradead.org, Eric Dumazet , linux-kernel@vger.kernel.org, Krzysztof Kozlowski , devicetree@vger.kernel.org Subject: Re: [PATCH net-next v2 03/35] dt-bindings: net: fman: Add additional interface properties Message-ID: <20220712193651.GL1823936-robh@kernel.org> References: <20220628221404.1444200-1-sean.anderson@seco.com> <20220628221404.1444200-4-sean.anderson@seco.com> <20220630160156.GA2745952-robh@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220712_123701_407800_40013B5E X-CRM114-Status: GOOD ( 56.90 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Jun 30, 2022 at 12:11:10PM -0400, Sean Anderson wrote: > Hi Rob, > > On 6/30/22 12:01 PM, Rob Herring wrote: > > On Tue, Jun 28, 2022 at 06:13:32PM -0400, Sean Anderson wrote: > >> At the moment, mEMACs are configured almost completely based on the > >> phy-connection-type. That is, if the phy interface is RGMII, it assumed > >> that RGMII is supported. For some interfaces, it is assumed that the > >> RCW/bootloader has set up the SerDes properly. This is generally OK, but > >> restricts runtime reconfiguration. The actual link state is never > >> reported. > >> > >> To address these shortcomings, the driver will need additional > >> information. First, it needs to know how to access the PCS/PMAs (in > >> order to configure them and get the link status). The SGMII PCS/PMA is > >> the only currently-described PCS/PMA. Add the XFI and QSGMII PCS/PMAs as > >> well. The XFI (and 1GBase-KR) PCS/PMA is a c45 "phy" which sits on the > >> same MDIO bus as SGMII PCS/PMA. By default they will have conflicting > >> addresses, but they are also not enabled at the same time by default. > >> Therefore, we can let the XFI PCS/PMA be the default when > >> phy-connection-type is xgmii. This will allow for > >> backwards-compatibility. > >> > >> QSGMII, however, cannot work with the current binding. This is because > >> the QSGMII PCS/PMAs are only present on one MAC's MDIO bus. At the > >> moment this is worked around by having every MAC write to the PCS/PMA > >> addresses (without checking if they are present). This only works if > >> each MAC has the same configuration, and only if we don't need to know > >> the status. Because the QSGMII PCS/PMA will typically be located on a > >> different MDIO bus than the MAC's SGMII PCS/PMA, there is no fallback > >> for the QSGMII PCS/PMA. > >> > >> mEMACs (across all SoCs) support the following protocols: > >> > >> - MII > >> - RGMII > >> - SGMII, 1000Base-X, and 1000Base-KX > >> - 2500Base-X (aka 2.5G SGMII) > >> - QSGMII > >> - 10GBase-R (aka XFI) and 10GBase-KR > >> - XAUI and HiGig > >> > >> Each line documents a set of orthogonal protocols (e.g. XAUI is > >> supported if and only if HiGig is supported). Additionally, > >> > >> - XAUI implies support for 10GBase-R > >> - 10GBase-R is supported if and only if RGMII is not supported > >> - 2500Base-X implies support for 1000Base-X > >> - MII implies support for RGMII > >> > >> To switch between different protocols, we must reconfigure the SerDes. > >> This is done by using the standard phys property. We can also use it to > >> validate whether different protocols are supported (e.g. using > >> phy_validate). This will work for serial protocols, but not RGMII or > >> MII. Additionally, we still need to be compatible when there is no > >> SerDes. > >> > >> While we can detect 10G support by examining the port speed (as set by > >> fsl,fman-10g-port), we cannot determine support for any of the other > >> protocols based on the existing binding. In fact, the binding works > >> against us in some respects, because pcsphy-handle is required even if > >> there is no possible PCS/PMA for that MAC. To allow for backwards- > >> compatibility, we use a boolean-style property for RGMII (instead of > >> presence/absence-style). When the property for RGMII is missing, we will > >> assume that it is supported. The exception is MII, since no existing > >> device trees use it (as far as I could tell). > >> > >> Unfortunately, QSGMII support will be broken for old device trees. There > >> is nothing we can do about this because of the PCS/PMA situation (as > >> described above). > >> > >> Signed-off-by: Sean Anderson > >> --- > >> > >> Changes in v2: > >> - Better document how we select which PCS to use in the default case > >> > >> .../bindings/net/fsl,fman-dtsec.yaml | 52 +++++++++++++++++-- > >> .../devicetree/bindings/net/fsl-fman.txt | 5 +- > >> 2 files changed, 51 insertions(+), 6 deletions(-) > >> > >> diff --git a/Documentation/devicetree/bindings/net/fsl,fman-dtsec.yaml b/Documentation/devicetree/bindings/net/fsl,fman-dtsec.yaml > >> index 809df1589f20..ecb772258164 100644 > >> --- a/Documentation/devicetree/bindings/net/fsl,fman-dtsec.yaml > >> +++ b/Documentation/devicetree/bindings/net/fsl,fman-dtsec.yaml > >> @@ -85,9 +85,41 @@ properties: > >> $ref: /schemas/types.yaml#/definitions/phandle > >> description: A reference to the IEEE1588 timer > >> > >> + phys: > >> + description: A reference to the SerDes lane(s) > >> + maxItems: 1 > >> + > >> + phy-names: > >> + items: > >> + - const: serdes > >> + > >> pcsphy-handle: > >> - $ref: /schemas/types.yaml#/definitions/phandle > >> - description: A reference to the PCS (typically found on the SerDes) > >> + $ref: /schemas/types.yaml#/definitions/phandle-array > >> + minItems: 1 > >> + maxItems: 3 > > > > What determines how many entries? > > It depends on what the particular MAC supports. From what I can tell, the following > combinations are valid: > > - Neither SGMII, QSGMII, or XFI > - Just SGMII > - Just QSGMII > - SGMII and QSGMII > - SGMII and XFI > - All of SGMII, QSGMII, and XFI > > All of these are used on different SoCs. So there will be a different PCS device for SGMII, QSGMII, and XFI rather than 1 PCS device that supports those 3 interfaces? > >> + description: | > >> + A reference to the various PCSs (typically found on the SerDes). If > >> + pcs-names is absent, and phy-connection-type is "xgmii", then the first > >> + reference will be assumed to be for "xfi". Otherwise, if pcs-names is > >> + absent, then the first reference will be assumed to be for "sgmii". > >> + > >> + pcs-names: > >> + $ref: /schemas/types.yaml#/definitions/string-array > >> + minItems: 1 > >> + maxItems: 3 > >> + contains: > >> + enum: > >> + - sgmii > >> + - qsgmii > >> + - xfi > > > > This means '"foo", "xfi", "bar"' is valid. I think you want to > > s/contains/items/. > > > >> + description: The type of each PCS in pcsphy-handle. > >> + > > > >> + rgmii: > >> + enum: [0, 1] > >> + description: 1 indicates RGMII is supported, and 0 indicates it is not. > >> + > >> + mii: > >> + description: If present, indicates that MII is supported. > > > > Types? Need vendor prefixes. > > OK. > > > Are these board specific or SoC specific? Properties are appropriate for > > the former. The latter case should be implied by the compatible string. > > Unfortunately, there are not existing specific compatible strings for each > device in each SoC. I suppose those could be added; however, this basically > reflects how each device is hooked up. E.g. on one SoC a device would be > connected to the RGMII pins, but not on another SoC. The MAC itself still > has hardware support for RGMII, but such a configuration would not function. A difference in instances on a given SoC would also be reason for properties rather than different compatible strings. However, we already have such properties. We have 'phy-connection-type' for which mode to use. Do you have some need to know all possible modes? I think there was something posted to allow 'phy-connection-type' to be an array of supported modes instead. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel