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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E0497ECAAD8 for ; Fri, 16 Sep 2022 04:55:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229550AbiIPEzY (ORCPT ); Fri, 16 Sep 2022 00:55:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54934 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229448AbiIPEzV (ORCPT ); Fri, 16 Sep 2022 00:55:21 -0400 Received: from lelv0142.ext.ti.com (lelv0142.ext.ti.com [198.47.23.249]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BF58B6A4B1; Thu, 15 Sep 2022 21:55:19 -0700 (PDT) Received: from lelv0266.itg.ti.com ([10.180.67.225]) by lelv0142.ext.ti.com (8.15.2/8.15.2) with ESMTP id 28G4ssqA060056; Thu, 15 Sep 2022 23:54:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1663304094; bh=DhgXN/2x1D5jdbzbm9/WulTVv5Ky25v+z/2Qoh7HaAQ=; h=Date:CC:Subject:To:References:From:In-Reply-To; b=kc56b1znp3iRWDdvyMyUFqCPpR9Bq2ZrDX9vEnPx0d/XbDU+TUp1q7hurCLF8S5P/ jxtvMBXb/xq4FIBAIO/Nq071EHDNUxPdQWv2pbWrU4K0gExmyIzSQAquOmiFEaKElg GfkXm2c3Q1iDwsKU4yNfT4YUp7a9Lk1rYOm84rIE= Received: from DFLE113.ent.ti.com (dfle113.ent.ti.com [10.64.6.34]) by lelv0266.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 28G4ssCe065132 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 15 Sep 2022 23:54:54 -0500 Received: from DFLE103.ent.ti.com (10.64.6.24) by DFLE113.ent.ti.com (10.64.6.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.6; Thu, 15 Sep 2022 23:54:54 -0500 Received: from lelv0326.itg.ti.com (10.180.67.84) by DFLE103.ent.ti.com (10.64.6.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.6 via Frontend Transport; Thu, 15 Sep 2022 23:54:54 -0500 Received: from [10.24.69.241] (ileaxei01-snat2.itg.ti.com [10.180.69.6]) by lelv0326.itg.ti.com (8.15.2/8.15.2) with ESMTP id 28G4smf0018522; Thu, 15 Sep 2022 23:54:49 -0500 Message-ID: Date: Fri, 16 Sep 2022 10:24:48 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 CC: , , , , , , , , , , , , , , , , Subject: Re: [PATCH 5/8] net: ethernet: ti: am65-cpsw: Add support for fixed-link configuration Content-Language: en-US To: "Russell King (Oracle)" References: <20220914095053.189851-1-s-vadapalli@ti.com> <20220914095053.189851-6-s-vadapalli@ti.com> From: Siddharth Vadapalli In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Russell, On 15/09/22 15:37, Russell King (Oracle) wrote: > Hi, > > On Thu, Sep 15, 2022 at 02:58:52PM +0530, Siddharth Vadapalli wrote: >> Hello Russell, >> >> On 14/09/22 21:39, Russell King (Oracle) wrote: >>> On Wed, Sep 14, 2022 at 03:20:50PM +0530, Siddharth Vadapalli wrote: >>>> Check for fixed-link in am65_cpsw_nuss_mac_config() using struct >>>> am65_cpsw_slave_data's phy_node property to obtain fwnode. Since >>>> am65_cpsw_nuss_mac_link_up() is not invoked in fixed-link mode, perform >>>> the relevant operations in am65_cpsw_nuss_mac_config() itself. >>> >>> Further to my other comments, you also fail to explain that, when in >>> fixed-link SGMII mode, you _emulate_ being a PHY - which I deduce >>> since you are sending the duplex setting and speed settings via the >>> SGMII control word. Also, as SGMII was invented for a PHY to be able >>> to communicate the media negotiation resolution to the MAC, SGMII >>> defines that the PHY fills in the speed and duplex information in >>> the control word to pass it to the MAC, and the MAC acknowledges this >>> information. There is no need (and SGMII doesn't permit) the MAC to >>> advertise what it's doing. >>> >>> Maybe this needs to be explained in the commit message? >> >> I had tested SGMII fixed-link mode using a bootstrapped ethernet layer-1 >> PHY. Based on your clarification in the previous mails that there is an >> issue with the fixed-link mode which I need to debug, I assume that what >> you are referring to here also happens to be a consequence of that. >> Please let me know if I have misunderstood what you meant to convey. > > I think what you're saying is that you have this setup: > > ethernet MAC <--SGMII link--> ethernet PHY <---> media > > which you are operating in fixed link mode? Yes, and the other end is connected to my PC's ethernet port. > > From the SGMII specification: "This is achieved by using the Auto- > Negotiation functionality defined in Clause 37 of the IEEE > Specification 802.3z. Instead of the ability advertisement, the PHY > sends the control information via its tx_config_Reg[15:0] as specified > in Table 1 whenever the control information changes. Upon receiving > control information, the MAC acknowledges the update of the control > information by asserting bit 14 of its tx_config_reg{15:0] as specified > in Table 1." > > For the control word sent from the MAC to the PHY, table 1 specifies a > value of 0x4001. All the zero bits in that word which are zero are > marked as "Reserved for future use." There are no fields for speed and > duplex in this acknowledgement word to the PHY. > > I hope this clears up my point. Thank you for the detailed explanation. After reading the above, my understanding is that even in the fixed-link mode, the ethernet MAC is not supposed to advertise the speed and duplex settings. The ethernet MACs present on both ends of the connection are supposed to be set to the same speed and duplex settings via the devicetree node. Thus, only for my setup which happens to be a special case of fixed-link mode where the ethernet PHY is present, I am having to send the control word due to the presence of a PHY in between. And, I am supposed to mention this in the commit message, which I haven't done. Please let me know if this is what I was supposed to understand. I am planning to change to a proper fixed-link setup without any ethernet PHY between the MACs, for debugging the driver's fixed-link mode where the "mac_link_up()" is not invoked. Additionally, with this new setup, my MAC will not have to emulate being an ethernet PHY, thereby making my patch cleaner in the process. The v2 series will be based on the new setup. I hope that this is fine. Regards, Siddharth. 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 532CDECAAD8 for ; Fri, 16 Sep 2022 04:56:19 +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:From:References:To:Subject: CC:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=f7mbzUIzGPRjmWrlAvXa6xeLnP/v63YcwVX/PdMvKbQ=; b=FxvD/BJcIr7hUQ 1xXyD1C4EBWdBcyC4aTrI9XaoJYQoKWKy8M/XktiYcwA/fBXE9CCjwkL3bvusezmPF/C/ymeF+o6N f020CfiWHIverhiPDyv4oXXlhRR4RYVe9hB0Iv33Q3X1fznbQtibnRWm7B//mSmAThrOyx3Q2CZDw Hs/lODppdLfh9P/2llgQnuKMO9lsxw5AQS3OA8JXO9qZGa6Fl1QWBkcTqSrgkA+YqmxmH1uPCeBpq kwG6rZXAu6JrKgBiDD+R3whMv6Xloy0WyWNwDXEVJOizkKv37KD4wLFNI7yZ8gCgJ9qkp25GZxbtr nzq1U6OfDs6+Il+Axd9Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oZ3Nk-007k93-Ut; Fri, 16 Sep 2022 04:55:17 +0000 Received: from lelv0142.ext.ti.com ([198.47.23.249]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oZ3Nh-007k1b-5y for linux-arm-kernel@lists.infradead.org; Fri, 16 Sep 2022 04:55:14 +0000 Received: from lelv0266.itg.ti.com ([10.180.67.225]) by lelv0142.ext.ti.com (8.15.2/8.15.2) with ESMTP id 28G4ssqA060056; Thu, 15 Sep 2022 23:54:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1663304094; bh=DhgXN/2x1D5jdbzbm9/WulTVv5Ky25v+z/2Qoh7HaAQ=; h=Date:CC:Subject:To:References:From:In-Reply-To; b=kc56b1znp3iRWDdvyMyUFqCPpR9Bq2ZrDX9vEnPx0d/XbDU+TUp1q7hurCLF8S5P/ jxtvMBXb/xq4FIBAIO/Nq071EHDNUxPdQWv2pbWrU4K0gExmyIzSQAquOmiFEaKElg GfkXm2c3Q1iDwsKU4yNfT4YUp7a9Lk1rYOm84rIE= Received: from DFLE113.ent.ti.com (dfle113.ent.ti.com [10.64.6.34]) by lelv0266.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 28G4ssCe065132 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 15 Sep 2022 23:54:54 -0500 Received: from DFLE103.ent.ti.com (10.64.6.24) by DFLE113.ent.ti.com (10.64.6.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.6; Thu, 15 Sep 2022 23:54:54 -0500 Received: from lelv0326.itg.ti.com (10.180.67.84) by DFLE103.ent.ti.com (10.64.6.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.6 via Frontend Transport; Thu, 15 Sep 2022 23:54:54 -0500 Received: from [10.24.69.241] (ileaxei01-snat2.itg.ti.com [10.180.69.6]) by lelv0326.itg.ti.com (8.15.2/8.15.2) with ESMTP id 28G4smf0018522; Thu, 15 Sep 2022 23:54:49 -0500 Message-ID: Date: Fri, 16 Sep 2022 10:24:48 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 CC: , , , , , , , , , , , , , , , , Subject: Re: [PATCH 5/8] net: ethernet: ti: am65-cpsw: Add support for fixed-link configuration Content-Language: en-US To: "Russell King (Oracle)" References: <20220914095053.189851-1-s-vadapalli@ti.com> <20220914095053.189851-6-s-vadapalli@ti.com> From: Siddharth Vadapalli In-Reply-To: X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220915_215513_427050_37A74F6B X-CRM114-Status: GOOD ( 29.02 ) 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 Hello Russell, On 15/09/22 15:37, Russell King (Oracle) wrote: > Hi, > > On Thu, Sep 15, 2022 at 02:58:52PM +0530, Siddharth Vadapalli wrote: >> Hello Russell, >> >> On 14/09/22 21:39, Russell King (Oracle) wrote: >>> On Wed, Sep 14, 2022 at 03:20:50PM +0530, Siddharth Vadapalli wrote: >>>> Check for fixed-link in am65_cpsw_nuss_mac_config() using struct >>>> am65_cpsw_slave_data's phy_node property to obtain fwnode. Since >>>> am65_cpsw_nuss_mac_link_up() is not invoked in fixed-link mode, perform >>>> the relevant operations in am65_cpsw_nuss_mac_config() itself. >>> >>> Further to my other comments, you also fail to explain that, when in >>> fixed-link SGMII mode, you _emulate_ being a PHY - which I deduce >>> since you are sending the duplex setting and speed settings via the >>> SGMII control word. Also, as SGMII was invented for a PHY to be able >>> to communicate the media negotiation resolution to the MAC, SGMII >>> defines that the PHY fills in the speed and duplex information in >>> the control word to pass it to the MAC, and the MAC acknowledges this >>> information. There is no need (and SGMII doesn't permit) the MAC to >>> advertise what it's doing. >>> >>> Maybe this needs to be explained in the commit message? >> >> I had tested SGMII fixed-link mode using a bootstrapped ethernet layer-1 >> PHY. Based on your clarification in the previous mails that there is an >> issue with the fixed-link mode which I need to debug, I assume that what >> you are referring to here also happens to be a consequence of that. >> Please let me know if I have misunderstood what you meant to convey. > > I think what you're saying is that you have this setup: > > ethernet MAC <--SGMII link--> ethernet PHY <---> media > > which you are operating in fixed link mode? Yes, and the other end is connected to my PC's ethernet port. > > From the SGMII specification: "This is achieved by using the Auto- > Negotiation functionality defined in Clause 37 of the IEEE > Specification 802.3z. Instead of the ability advertisement, the PHY > sends the control information via its tx_config_Reg[15:0] as specified > in Table 1 whenever the control information changes. Upon receiving > control information, the MAC acknowledges the update of the control > information by asserting bit 14 of its tx_config_reg{15:0] as specified > in Table 1." > > For the control word sent from the MAC to the PHY, table 1 specifies a > value of 0x4001. All the zero bits in that word which are zero are > marked as "Reserved for future use." There are no fields for speed and > duplex in this acknowledgement word to the PHY. > > I hope this clears up my point. Thank you for the detailed explanation. After reading the above, my understanding is that even in the fixed-link mode, the ethernet MAC is not supposed to advertise the speed and duplex settings. The ethernet MACs present on both ends of the connection are supposed to be set to the same speed and duplex settings via the devicetree node. Thus, only for my setup which happens to be a special case of fixed-link mode where the ethernet PHY is present, I am having to send the control word due to the presence of a PHY in between. And, I am supposed to mention this in the commit message, which I haven't done. Please let me know if this is what I was supposed to understand. I am planning to change to a proper fixed-link setup without any ethernet PHY between the MACs, for debugging the driver's fixed-link mode where the "mac_link_up()" is not invoked. Additionally, with this new setup, my MAC will not have to emulate being an ethernet PHY, thereby making my patch cleaner in the process. The v2 series will be based on the new setup. I hope that this is fine. Regards, Siddharth. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel