Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp2228523rwl; Fri, 6 Jan 2023 03:45:48 -0800 (PST) X-Google-Smtp-Source: AMrXdXu+tbpZw7VT7IsXUiRCyME8bbJznU7tUIf1WRXrbQ4ALIEfcnJtYz//xI5cDqPm8RI27fK2 X-Received: by 2002:a17:906:b00c:b0:7c4:fa17:7202 with SMTP id v12-20020a170906b00c00b007c4fa177202mr45276400ejy.33.1673005548337; Fri, 06 Jan 2023 03:45:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673005548; cv=none; d=google.com; s=arc-20160816; b=xkKxqQIU9BWOWuV/q7NadAx7QXPyZ8i5i2JaVQjNOfEIPpOBHe6p/T/lTbzyxyAFfa hS+rL4nb3h+P9chM4F3cI7aDx6i529U47OnTWXWT+UgzHI5QnNwoTQepv/BpxtmRRbAE djd1TZPMJN2rfTeL7ZKLN7vA1fD/B5DMLLHChLkts0Dx7U8FOuiPTa627ppmv1OJ5UGC QqMl+5IHiU5P8DOk6MKqGu8T6bRCgvM2x+u37MQ5IpiAMjrug09lUnZkLqLqUXOU/X4m QXhfKaBM2ntNaeC7QmvmDaP3859WlU2uHWBhHvSrjRz1s2HyDXNN+WcmjOMZqKyGdYBz 86sg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=xSIYp0jVy+zrTKve9Gpxn98ZK35qEbotLOMoDwC9jkc=; b=UmniFjCxJeiBGCIm0qiJaXoNBwBidk6ISdNQQ4aryJm7Q52BifO9hgnFenuOVuQ9zU Q8zmrZk3FY5CX3CWzkl0AMa/oE9SIUlxY35FlWK6C62OpvmTcAzVlbc3Ztd4tTJDMkXi bMU0CyPC7EFBPr8uC53cOhbHIZDu3oy48DsKks/QxIl7zzPPV3Nxnnh6tS88n9VZ3yje s7FoTim14TdGLFUCfTZPs3LrTZwNYq2kcn4vk3cWKfnjClBkEH75cU49Ic8IFZ9LnnkK bbFIh78KSiKj1Gfl5Jq6ZUeGbwSxTSkJvvZv5yeRBwGL79e/hiJwjdm0n4uZ5gHbuVGz 0+Sw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=umc1j0Gz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t18-20020a1709063e5200b007ac9a51342asi815433eji.188.2023.01.06.03.45.34; Fri, 06 Jan 2023 03:45:48 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=umc1j0Gz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230047AbjAFLP0 (ORCPT + 54 others); Fri, 6 Jan 2023 06:15:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55894 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229472AbjAFLPY (ORCPT ); Fri, 6 Jan 2023 06:15:24 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5E1006EC95; Fri, 6 Jan 2023 03:15:23 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 1248CB81CDE; Fri, 6 Jan 2023 11:15:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B1EB8C433D2; Fri, 6 Jan 2023 11:15:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1673003720; bh=AY+EUNxLVUahOuHk2agSSXRRnUVJYLimnavTHNTsJKo=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=umc1j0Gz4jTDpUKZHCfkiq2xV3+7ElDvGTdxk6s3o9EAXFkWJTnzP1elSSzA5uUs6 j377WuTFRWf7a7zE1yVlOLpfqMVGJnta26ErNs4FjOmx7Ai+56CUjCvohJ83jHYX98 Zpnf9tYghb9SJZvpjDt7Ykmgke0OPIJjX6M9kidWzuKv6CidNWiU0GhzgFUXqnHZIB G9CjUnS1lOiMHm0RUJiav/cMIby7ZrFcvu2Y9yD506q0/LJCITGNuEl1Ji1qex88oD OC0hqtJx3Mn/aGMC1Yj6sDtaN/E3rHiDfwyq1aCdKk//UtjB4uhCl0cYbmDRHl9s1B wuiRe59zIQbUQ== Message-ID: Date: Fri, 6 Jan 2023 13:15:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [PATCH v3 1/2] dt-bindings: net: Add ICSSG Ethernet Driver bindings Content-Language: en-US To: Andrew Lunn Cc: Md Danish Anwar , "Andrew F. Davis" , Tero Kristo , Suman Anna , YueHaibing , Vignesh Raghavendra , Krzysztof Kozlowski , Rob Herring , Paolo Abeni , Jakub Kicinski , Eric Dumazet , "David S. Miller" , nm@ti.com, ssantosh@kernel.org, srk@ti.com, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, netdev@vger.kernel.org, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org References: <20221223110930.1337536-1-danishanwar@ti.com> <20221223110930.1337536-2-danishanwar@ti.com> <620ce8e6-2b40-1322-364a-0099a6e2af26@kernel.org> From: Roger Quadros In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-10.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/01/2023 19:13, Andrew Lunn wrote: >>>> On 23/12/2022 16:28, Andrew Lunn wrote: >>>>>> + ethernet-ports { >>>>>> + #address-cells = <1>; >>>>>> + #size-cells = <0>; >>>>>> + pruss2_emac0: port@0 { >>>>>> + reg = <0>; >>>>>> + phy-handle = <&pruss2_eth0_phy>; >>>>>> + phy-mode = "rgmii-rxid"; >>>>> >>>>> That is unusual. Where are the TX delays coming from? >>>> >>>> >From the below property >>>> >>>> + ti,syscon-rgmii-delay = <&scm_conf 0x4120>; >>>> >>>> The TX delay can be enabled/disabled from within the ICSSG block. >>>> >>>> If this property exists and PHY mode is neither PHY_INTERFACE_MODE_RGMII_ID >>>> nor PHY_INTERFACE_MODE_RGMII_TXID then the internal delay is enabled. >>>> >>>> This logic is in prueth_config_rgmiidelay() function in the introduced driver. >>> >>> What nearly every other MAC driver does is pass the phy-mode to the >>> PHY and lets the PHY add the delays. I would recommend you do that, >>> rather than be special and different. >> >> >> If I remember right we couldn't disable MAC TX delay on some earlier silicon >> so had to take this route. I don't remember why we couldn't disable it though. >> >> In more recent Silicon Manuals I do see that MAC TX delay can be enabled/disabled. >> If this really is the case then we should change to >> >> phy-mode = "rgmii-id"; >> >> And let PHY handle the TX+RX delays. > > DT describes the board. PHY mode indicates what delays the board > requires, because the board itself is not performing the delays by > using extra long lines. So typically, phy-mode is rgmii-id, indicating > delays need to be added somewhere in both directions. > > Who adds the delays is then between the MAC and the PHY. In most > cases, the MAC does nothing, and passes phy-mode to the PHY and the > PHY does it. > > But it is also possible for the MAC to do the delay. So if you cannot > actually disable the TX delay in the MAC, that is O.K. But you need to > modify phy-mode you pass to the PHY to indicate the MAC is doing the > delay, otherwise the PHY will additionally do the delay. So your DT > will contain rgmii-id, because that is what the board requires, but > the MAC will pass rmgii-rxid to the PHY, since that is what the PHY > needs to add. Thanks for the explanation. :) cheers, -roger