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 DB9EDC43334 for ; Mon, 27 Jun 2022 23:07:00 +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=gfxE1lqFa4QWFJ3qLB/ZCVDVhpblDJvQSKXRoRqCxhE=; b=47mfHiLECsgvjt kxJpKFr+PNuGzL55ahogxPvVTwK4YfadCql/jAaq+WOd9RgW6yThOnsUeXwAPjTfUIgjRZPsIolcw a4kQq7ax9Xlo06OQG/dI2pQKuxL/PHCvDz/laVjeu0oImfltycvJ41UOUR/eYAwMjXwZEK2rWz2JU fC4rqCfrJkDsPY9AwZ8FgWTwaUd5WToPvU+2mHUyBBYnbJe6IlCmAgmiqCDRveZvjpHzLF1/wXXBk 0SvBRDeMhw6aklREFz6hztzFtPBqgPUCwE3jWWxvRnju2+i/sT6Zy4Mh1joydUASPOw4OssMfCxKu yX7x/RoGgrJcwJMx3LmA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o5xns-003CoJ-PM; Mon, 27 Jun 2022 23:06:00 +0000 Received: from mail-io1-f51.google.com ([209.85.166.51]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1o5xnp-003CkF-F6 for linux-arm-kernel@lists.infradead.org; Mon, 27 Jun 2022 23:05:58 +0000 Received: by mail-io1-f51.google.com with SMTP id p69so11186402iod.10 for ; Mon, 27 Jun 2022 16:05:48 -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=RsbxMGrAEPpDrcq9SD5GCJ241orHnQShiio8WLL4UIU=; b=4t9/KvytGZieXpfmVVgrHnb8dr3Kou0PIzxfo1r4cPuhNKksJBEDVvYP3JlC7+K8Aq MNQO4Rtw+AJvdZgmNLt8543LJviC8oJGMB2f49sEmA5VORuKguGnLXqXE40T1m0z5kgY mzKwVFDE5VAKPLiOBFHAtlHCmYY2K5vgOyBzp2T5E2VnsZL1f0HADdfGZcLBTmOp/JC7 ehoIhx4rPNQ4/7GB/i7UFVBZe5QjJud7HHNkyNZ+xibOkwvwyRorr9wN4WZCByt26zw0 hhMeW/kNp/zLDeIGSDaDdkTa2bY04UhXV/giXR8VifAnJ/pFu4gg/MyYZ2IPnn11HeT+ d8jQ== X-Gm-Message-State: AJIora/KXNfmPg/mtg7upw4DyRzVsCZR7l2WEG1z0vQzKa/qYk25x/aU POYNZitk8Zw8nuZeu+zq9dr0CCLkpQ== X-Google-Smtp-Source: AGRyM1usk/wrttz5ONExBVqjv9hoJ7YL8ko7p4t0WyBusRIAayBBYIv7q93475PYWubiuUWy74YCpg== X-Received: by 2002:a02:a08d:0:b0:33c:6a7d:87db with SMTP id g13-20020a02a08d000000b0033c6a7d87dbmr7505895jah.64.1656371147890; Mon, 27 Jun 2022 16:05:47 -0700 (PDT) Received: from robh.at.kernel.org ([64.188.179.253]) by smtp.gmail.com with ESMTPSA id t64-20020a025443000000b0033b73557de4sm5156297jaa.93.2022.06.27.16.05.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Jun 2022 16:05:47 -0700 (PDT) Received: (nullmailer pid 3134751 invoked by uid 1000); Mon, 27 Jun 2022 23:05:45 -0000 Date: Mon, 27 Jun 2022 17:05:45 -0600 From: Rob Herring To: Krzysztof Kozlowski Cc: Sean Anderson , "David S . Miller" , Jakub Kicinski , Madalin Bucur , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Paolo Abeni , Russell King , Eric Dumazet , Krzysztof Kozlowski , devicetree@vger.kernel.org Subject: Re: [PATCH net-next 02/28] dt-bindings: net: fman: Add additional interface properties Message-ID: <20220627230545.GA3128808-robh@kernel.org> References: <20220617203312.3799646-1-sean.anderson@seco.com> <20220617203312.3799646-3-sean.anderson@seco.com> <4b305b67-7bc1-d188-23b8-6e5c7e81813b@seco.com> <9c0513dd-67ce-0d6a-f2a5-58e981f0d55c@linaro.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <9c0513dd-67ce-0d6a-f2a5-58e981f0d55c@linaro.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220627_160557_545548_788C9D10 X-CRM114-Status: GOOD ( 44.54 ) 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 Sun, Jun 19, 2022 at 12:33:22PM +0200, Krzysztof Kozlowski wrote: > On 18/06/2022 17:55, Sean Anderson wrote: > > Hi Krzysztof, > > > > On 6/17/22 9:16 PM, Krzysztof Kozlowski wrote: > >> On 17/06/2022 13:32, 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. 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 default address for the XFI PCS/PMA be the > >>> same as for SGMII. 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 > >> > >> Thanks for the patch but you add too many new properties. The file > >> should be converted to YAML/DT schema first. > > > > Perhaps. However, conversion to yaml is a non-trivial task, especially for > > a complicated binding such as this one. I am more than happy to rework this > > patch to be based on a yaml conversion, but I do not have the bandwidth to > > do so myself. > > I understand. Although since 2020 - since when we expect the bindings > to be in YAML - this file grew by 6 properties, because each person > extends it instead of converting. Each person uses the same excuse... > > You add here 5 more, so it would be 11 new properties in total. > > > > > If you have any comments on the binding changes themselves, that would be > > much appreciated. > > Maybe Rob will ack it, but for me the change is too big to be accepted > in TXT, so no from me. Above my threshold for not first converting too. Really, I'm pretty close to saying no .txt file changes at all. Maybe compatible string updates only, people should be rewarded for not changing their h/w. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel