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 8B0B2C7EE29 for ; Sun, 4 Jun 2023 15:14:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Cc:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject: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=bleTwqLDy63DUKjND0vhxknWwf9IMmoH1kBo/dk1g7E=; b=EFMpF4jC+vy1vcIMJMO33AkcRd kXNrVoLanjT/9KAzsDibmDHW11C2UqfhLaNrbPJQx/1+Qyp158U+urfz3qYv637W//87esjDWTPda R+tCSPeUZV8sucZKrkjuF97XqgaHp07Sah3fNh4cdPiQvr4vfk4r54Cfo0+IR50LgQgQDBy4ZYAS2 RCL/Y+fFk5tLyFBF3jwmRzpr3Dc5aKeAWxLP7p49GWxJpCqxBCGMKpG77w6qmlQTkhfHNQhznACIi JbnWJPHGeWQnxD1YUMCi9Oi+QPToQsT10ohlXtYgyfK5DXbQ4DYTVwTJ4cCH8tnaioHMJDm5U3tnD diDYlLGw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q5pQw-00CMOT-14; Sun, 04 Jun 2023 15:14:18 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1q5pQs-00CMNs-2D; Sun, 04 Jun 2023 15:14:16 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To: Content-Transfer-Encoding:Content-Type: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-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=bleTwqLDy63DUKjND0vhxknWwf9IMmoH1kBo/dk1g7E=; b=XC5ajlHrTHkMlFDqkqNWH1oZJY sVDDIMYBBA8B8P3k9AYiopTZhWhx9pehmlZA85PPrw4w234JrYGvdN8k5BcyQ/RWU9+yHjGPyzCph VgxT5vETval6ij6ANVR+7lAN1E0sMlEx02+a2vWs1/4E2EVZpsgbDQjAX2G+0I9nRXInMRh691k2t +duMlyG186mcHE3WUJyYUhi/HfQT6yE0sNRQNcK4D+By0iAyMROuEsxiQ9w8GihvOrxmfFl/gRDaL ubyr9R6elsjoSNlkVbKtqiynH8Z4t8e0G3cLToDhBgSVOksTEzw88n2qTH3F4p97QRF6J68DI6gPH Ym4G3sPQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:43062) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1q5pQU-0002iu-Uo; Sun, 04 Jun 2023 16:13:50 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1q5pQJ-0005A1-GU; Sun, 04 Jun 2023 16:13:39 +0100 Date: Sun, 4 Jun 2023 16:13:39 +0100 From: "Russell King (Oracle)" To: =?utf-8?B?QXLEsW7DpyDDnE5BTA==?= Subject: Re: [PATCH net-next 08/30] net: dsa: mt7530: change p{5,6}_interface to p{5,6}_configured Message-ID: References: <20230524175107.hwzygo7p4l4rvawj@skbuf> <576f92b0-1900-f6ff-e92d-4b82e3436ea1@arinc9.com> <20230526130145.7wg75yoe6ut4na7g@skbuf> <7117531f-a9f2-63eb-f69d-23267e5745d0@arinc9.com> <826fd2fc-fbf8-dab7-9c90-b726d15e2983@arinc9.com> <20230604125517.fwqh2uxzvsa7n5hu@skbuf> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230604_081414_887127_4A0602DE X-CRM114-Status: GOOD ( 29.07 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Andrew Lunn , linux-kernel@vger.kernel.org, Eric Dumazet , mithat.guner@xeront.com, Florian Fainelli , erkin.bozoglu@xeront.com, Richard van Schagen , Jakub Kicinski , Paolo Abeni , Landen Chao , Richard van Schagen , Sean Wang , DENG Qingfang , linux-mediatek@lists.infradead.org, Bartel Eerdekens , Matthias Brugger , linux-arm-kernel@lists.infradead.org, AngeloGioacchino Del Regno , netdev@vger.kernel.org, Daniel Golle , Vladimir Oltean , "David S. Miller" Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org On Sun, Jun 04, 2023 at 04:14:31PM +0300, Arınç ÜNAL wrote: > On 4.06.2023 16:07, Russell King (Oracle) wrote: > > On Sun, Jun 04, 2023 at 03:55:17PM +0300, Vladimir Oltean wrote: > > > On Sun, Jun 04, 2023 at 01:18:04PM +0100, Russell King (Oracle) wrote: > > > > I don't remember whether Vladimir's firmware validator will fail for > > > > mt753x if CPU ports are not fully described, but that would be well > > > > worth checking. If it does, then we can be confident that phylink > > > > will always be used, and those bypassing calls should not be necessary. > > > > > > It does, I've just retested this: > > > > > > [ 8.469152] mscc_felix 0000:00:00.5: OF node /soc/pcie@1f0000000/ethernet-switch@0,5/ports/port@4 of CPU port 4 lacks the required "phy-handle", "fixed-link" or "managed" properties > > > [ 8.494571] mscc_felix 0000:00:00.5: error -EINVAL: Failed to register DSA switch > > > [ 8.502151] mscc_felix: probe of 0000:00:00.5 failed with error -22 > > > > ... which isn't listed in dsa_switches_apply_workarounds[], and > > neither is mt753x. Thanks. > > > > So, that should be sufficient to know that the CPU port will always > > properly described, and thus bypassing phylink in mt753x for the CPU > > port should not be necessary. > > Perfect! If I understand correctly, there's this code - specific to MT7531 > and MT7988 ports being used as CPU ports - which runs in addition to what's > in mt753x_phylink_mac_config(): > > mt7530_write(priv, MT7530_PMCR_P(port), > PMCR_CPU_PORT_SETTING(priv->id)); > > This should be put on mt753x_phylink_mac_config(), under priv->id == > ID_MT7531, priv->id == ID_MT7988, and dsa_is_cpu_port(ds, port) checks? Please remember that I have very little knowledge of MT753x, so in order to answer this question, I've read through the mt7530 driver code. Looking at mt7530.h: #define PMCR_CPU_PORT_SETTING(id) (PMCR_FORCE_MODE_ID((id)) | \ PMCR_IFG_XMIT(1) | PMCR_MAC_MODE | \ PMCR_BACKOFF_EN | PMCR_BACKPR_EN | \ PMCR_TX_EN | PMCR_RX_EN | \ PMCR_TX_FC_EN | PMCR_RX_FC_EN | \ PMCR_FORCE_SPEED_1000 | \ PMCR_FORCE_FDX | PMCR_FORCE_LNK) This seems to be some kind of port control register that sets amongst other things parameters such as whether flow control is enabled, the port speed, the duplex setting, whether link is forced up, etc. Looking at what mt753x_phylink_mac_link_up() does: 1. it sets PMCR_RX_EN | PMCR_TX_EN | PMCR_FORCE_LNK. 2. it sets PMCR_FORCE_SPEED_1000 if speed was 1000Mbps, or if using an internal, TRGMII, 1000base-X or 2500base-X phy interface mode. 3. it sets PMCR_FORCE_FDX if full duplex was requested. 4. it sets PMCR_TX_FC_EN if full duplex was requested with tx pause. 5. it sets PMCR_RX_FC_EN if full duplex was requested with rx pause. So, provided this is called with the appropriate parameters, for a fixed link, that will leave the following: PMCR_FORCE_MODE_ID(id) PMCR_IFG_XMIT(1) PMCR_MAC_MODE PMCR_BACKOFF_EN PMCR_BACKPR_EN If we now look at mt753x_phylink_mac_config(), this sets PMCR_IFG_XMIT(1), PMCR_MAC_MODE, PMCR_BACKOFF_EN, PMCR_BACKPR_EN, and PMCR_FORCE_MODE_ID(priv->id), which I believe is everything that PMCR_CPU_PORT_SETTING(priv->id) is doing. So, Wouldn't a fixed-link description indicating 1Gbps, full duplex with pause cause phylink to call both mt753x_phylink_mac_config() and mt753x_phylink_mac_link_up() with appropriate arguments to set all of these parameters in PMCR? Now, I'm going to analyse something else. mt7531_cpu_port_config() is called from mt753x_cpu_port_enable(), which is itself called from mt7531_setup_common(). That is ultimately called from the DSA switch ops .setup() method. This method is called from dsa_switch_setup() for each switch in the DSA tree. dsa_tree_setup_switches() calls this, and is called from dsa_tree_setup(). Once dsa_tree_setup_switches() finishes successfully, dsa_tree_setup_ports() will be called. This will then setup DSA and CPU ports, which will then setup a phylink instance for these ports. phylink will parse the firmware description for the port. DSA will then call dsa_port_enable(). dsa_port_enable() will then call any port_enable() method in the mt7530.c driver, which will be mt7530_port_enable(). This then... mt7530_clear(priv, MT7530_PMCR_P(port), PMCR_LINK_SETTINGS_MASK); which is: #define PMCR_LINK_SETTINGS_MASK (PMCR_TX_EN | PMCR_FORCE_SPEED_1000 | \ PMCR_RX_EN | PMCR_FORCE_SPEED_100 | \ PMCR_TX_FC_EN | PMCR_RX_FC_EN | \ PMCR_FORCE_FDX | PMCR_FORCE_LNK | \ PMCR_FORCE_EEE1G | PMCR_FORCE_EEE100) So it wipes out all the PMCR settings that mt7531_cpu_port_config() performed - undoing *everything* below that switch() statement in mt7531_cpu_port_config()! Once the port_enable() method returns, DSA will then call phylink_start(), which will trigger phylink to bring up the link according to the settings it has, which will mean phylink calls the mac_config(), pcs_config(), pcs_link_up() and mac_link_up() with the appropriate parameters for the firmware described link. So I think I have the answer to my initial thought: do the calls in mt7531_cpu_port_config() to the phylink methods have any use what so ever? The answer is no, they are entirely useless. The same goes for the other cpu_port_config() methods that do something similar. The same goes for the PMCR register write that's changing any bits included in PMCR_LINK_SETTINGS_MASK. What that means is that mt7988_cpu_port_config() can be entirely removed, it serves no useful purpose what so ever. For mt7531_cpu_port_config(), it only needs to set priv->p[56]_interface which, as far as I can see, probably only avoids mac_config() doing any pad setup (that's a guess.) At least that's what I gather from reading through the driver and DSA code. It may be I've missed something, but currently, I think that these cpu_port_config() functions aren't doing too much that is actually useful work. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last! 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 F3F9BC7EE23 for ; Sun, 4 Jun 2023 15:14:53 +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=IY8PLE5EeWKghIdtfVFJ3Idl/dyLvPzpEkp97v3wVO4=; b=4gvC5s2t6KsDkz TgN5h2EmTcbPzeTfCPFSkDxKmNcb1GGtOS8OL+eQiZSj9U1jR3FErv3kwY7luNDIN/i3bJkogtifN nibqE/CYcN+fI8pX7MV4gD9XmgKrUxpyJgZpoZUw3+yxq2rEcb6fUQA6nEH9bsnQ9pUaZa6g4Gj8f 3G+8tMR1PNwZNXKQQHYf0AnXM9JCqvCe4oZ7Onka2xQ/ZEdsr2IgHKHAPOVQUJoLUGzXr672Ljo2q K2egPsMq08WstAo5/nGUOnmNS/CFL/sz64XGsnPfJlUggPYNxLXgh40mE6TZwdklDIAO5ICJJKlaF cP8nJqbQVNLnp6+GP1rg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q5pQv-00CMON-2b; Sun, 04 Jun 2023 15:14:17 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1q5pQs-00CMNs-2D; Sun, 04 Jun 2023 15:14:16 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To: Content-Transfer-Encoding:Content-Type: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-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=bleTwqLDy63DUKjND0vhxknWwf9IMmoH1kBo/dk1g7E=; b=XC5ajlHrTHkMlFDqkqNWH1oZJY sVDDIMYBBA8B8P3k9AYiopTZhWhx9pehmlZA85PPrw4w234JrYGvdN8k5BcyQ/RWU9+yHjGPyzCph VgxT5vETval6ij6ANVR+7lAN1E0sMlEx02+a2vWs1/4E2EVZpsgbDQjAX2G+0I9nRXInMRh691k2t +duMlyG186mcHE3WUJyYUhi/HfQT6yE0sNRQNcK4D+By0iAyMROuEsxiQ9w8GihvOrxmfFl/gRDaL ubyr9R6elsjoSNlkVbKtqiynH8Z4t8e0G3cLToDhBgSVOksTEzw88n2qTH3F4p97QRF6J68DI6gPH Ym4G3sPQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:43062) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1q5pQU-0002iu-Uo; Sun, 04 Jun 2023 16:13:50 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1q5pQJ-0005A1-GU; Sun, 04 Jun 2023 16:13:39 +0100 Date: Sun, 4 Jun 2023 16:13:39 +0100 From: "Russell King (Oracle)" To: =?utf-8?B?QXLEsW7DpyDDnE5BTA==?= Cc: Vladimir Oltean , Sean Wang , Landen Chao , DENG Qingfang , Daniel Golle , Andrew Lunn , Florian Fainelli , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Matthias Brugger , AngeloGioacchino Del Regno , Richard van Schagen , Richard van Schagen , Frank Wunderlich , Bartel Eerdekens , erkin.bozoglu@xeront.com, mithat.guner@xeront.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org Subject: Re: [PATCH net-next 08/30] net: dsa: mt7530: change p{5,6}_interface to p{5,6}_configured Message-ID: References: <20230524175107.hwzygo7p4l4rvawj@skbuf> <576f92b0-1900-f6ff-e92d-4b82e3436ea1@arinc9.com> <20230526130145.7wg75yoe6ut4na7g@skbuf> <7117531f-a9f2-63eb-f69d-23267e5745d0@arinc9.com> <826fd2fc-fbf8-dab7-9c90-b726d15e2983@arinc9.com> <20230604125517.fwqh2uxzvsa7n5hu@skbuf> 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-20230604_081414_887127_4A0602DE X-CRM114-Status: GOOD ( 29.07 ) 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="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org T24gU3VuLCBKdW4gMDQsIDIwMjMgYXQgMDQ6MTQ6MzFQTSArMDMwMCwgQXLEsW7DpyDDnE5BTCB3 cm90ZToKPiBPbiA0LjA2LjIwMjMgMTY6MDcsIFJ1c3NlbGwgS2luZyAoT3JhY2xlKSB3cm90ZToK PiA+IE9uIFN1biwgSnVuIDA0LCAyMDIzIGF0IDAzOjU1OjE3UE0gKzAzMDAsIFZsYWRpbWlyIE9s dGVhbiB3cm90ZToKPiA+ID4gT24gU3VuLCBKdW4gMDQsIDIwMjMgYXQgMDE6MTg6MDRQTSArMDEw MCwgUnVzc2VsbCBLaW5nIChPcmFjbGUpIHdyb3RlOgo+ID4gPiA+IEkgZG9uJ3QgcmVtZW1iZXIg d2hldGhlciBWbGFkaW1pcidzIGZpcm13YXJlIHZhbGlkYXRvciB3aWxsIGZhaWwgZm9yCj4gPiA+ ID4gbXQ3NTN4IGlmIENQVSBwb3J0cyBhcmUgbm90IGZ1bGx5IGRlc2NyaWJlZCwgYnV0IHRoYXQg d291bGQgYmUgd2VsbAo+ID4gPiA+IHdvcnRoIGNoZWNraW5nLiBJZiBpdCBkb2VzLCB0aGVuIHdl IGNhbiBiZSBjb25maWRlbnQgdGhhdCBwaHlsaW5rCj4gPiA+ID4gd2lsbCBhbHdheXMgYmUgdXNl ZCwgYW5kIHRob3NlIGJ5cGFzc2luZyBjYWxscyBzaG91bGQgbm90IGJlIG5lY2Vzc2FyeS4KPiA+ ID4gCj4gPiA+IEl0IGRvZXMsIEkndmUganVzdCByZXRlc3RlZCB0aGlzOgo+ID4gPiAKPiA+ID4g WyAgICA4LjQ2OTE1Ml0gbXNjY19mZWxpeCAwMDAwOjAwOjAwLjU6IE9GIG5vZGUgL3NvYy9wY2ll QDFmMDAwMDAwMC9ldGhlcm5ldC1zd2l0Y2hAMCw1L3BvcnRzL3BvcnRANCBvZiBDUFUgcG9ydCA0 IGxhY2tzIHRoZSByZXF1aXJlZCAicGh5LWhhbmRsZSIsICJmaXhlZC1saW5rIiBvciAibWFuYWdl ZCIgcHJvcGVydGllcwo+ID4gPiBbICAgIDguNDk0NTcxXSBtc2NjX2ZlbGl4IDAwMDA6MDA6MDAu NTogZXJyb3IgLUVJTlZBTDogRmFpbGVkIHRvIHJlZ2lzdGVyIERTQSBzd2l0Y2gKPiA+ID4gWyAg ICA4LjUwMjE1MV0gbXNjY19mZWxpeDogcHJvYmUgb2YgMDAwMDowMDowMC41IGZhaWxlZCB3aXRo IGVycm9yIC0yMgo+ID4gCj4gPiAuLi4gd2hpY2ggaXNuJ3QgbGlzdGVkIGluIGRzYV9zd2l0Y2hl c19hcHBseV93b3JrYXJvdW5kc1tdLCBhbmQKPiA+IG5laXRoZXIgaXMgbXQ3NTN4LiBUaGFua3Mu Cj4gPiAKPiA+IFNvLCB0aGF0IHNob3VsZCBiZSBzdWZmaWNpZW50IHRvIGtub3cgdGhhdCB0aGUg Q1BVIHBvcnQgd2lsbCBhbHdheXMKPiA+IHByb3Blcmx5IGRlc2NyaWJlZCwgYW5kIHRodXMgYnlw YXNzaW5nIHBoeWxpbmsgaW4gbXQ3NTN4IGZvciB0aGUgQ1BVCj4gPiBwb3J0IHNob3VsZCBub3Qg YmUgbmVjZXNzYXJ5Lgo+IAo+IFBlcmZlY3QhIElmIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHksIHRo ZXJlJ3MgdGhpcyBjb2RlIC0gc3BlY2lmaWMgdG8gTVQ3NTMxCj4gYW5kIE1UNzk4OCBwb3J0cyBi ZWluZyB1c2VkIGFzIENQVSBwb3J0cyAtIHdoaWNoIHJ1bnMgaW4gYWRkaXRpb24gdG8gd2hhdCdz Cj4gaW4gbXQ3NTN4X3BoeWxpbmtfbWFjX2NvbmZpZygpOgo+IAo+IAltdDc1MzBfd3JpdGUocHJp diwgTVQ3NTMwX1BNQ1JfUChwb3J0KSwKPiAJCSAgICAgUE1DUl9DUFVfUE9SVF9TRVRUSU5HKHBy aXYtPmlkKSk7Cj4gCj4gVGhpcyBzaG91bGQgYmUgcHV0IG9uIG10NzUzeF9waHlsaW5rX21hY19j b25maWcoKSwgdW5kZXIgcHJpdi0+aWQgPT0KPiBJRF9NVDc1MzEsIHByaXYtPmlkID09IElEX01U Nzk4OCwgYW5kIGRzYV9pc19jcHVfcG9ydChkcywgcG9ydCkgY2hlY2tzPwoKUGxlYXNlIHJlbWVt YmVyIHRoYXQgSSBoYXZlIHZlcnkgbGl0dGxlIGtub3dsZWRnZSBvZiBNVDc1M3gsIHNvIGluCm9y ZGVyIHRvIGFuc3dlciB0aGlzIHF1ZXN0aW9uLCBJJ3ZlIHJlYWQgdGhyb3VnaCB0aGUgbXQ3NTMw IGRyaXZlcgpjb2RlLgoKTG9va2luZyBhdCBtdDc1MzAuaDoKCiNkZWZpbmUgIFBNQ1JfQ1BVX1BP UlRfU0VUVElORyhpZCkgICAgICAoUE1DUl9GT1JDRV9NT0RFX0lEKChpZCkpIHwgXAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBNQ1JfSUZHX1hNSVQoMSkgfCBQTUNS X01BQ19NT0RFIHwgXAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBN Q1JfQkFDS09GRl9FTiB8IFBNQ1JfQkFDS1BSX0VOIHwgXAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFBNQ1JfVFhfRU4gfCBQTUNSX1JYX0VOIHwgXAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBNQ1JfVFhfRkNfRU4gfCBQTUNSX1JYX0ZD X0VOIHwgXAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBNQ1JfRk9S Q0VfU1BFRURfMTAwMCB8IFwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBQTUNSX0ZPUkNFX0ZEWCB8IFBNQ1JfRk9SQ0VfTE5LKQoKVGhpcyBzZWVtcyB0byBiZSBzb21l IGtpbmQgb2YgcG9ydCBjb250cm9sIHJlZ2lzdGVyIHRoYXQgc2V0cyBhbW9uZ3N0Cm90aGVyIHRo aW5ncyBwYXJhbWV0ZXJzIHN1Y2ggYXMgd2hldGhlciBmbG93IGNvbnRyb2wgaXMgZW5hYmxlZCwg dGhlCnBvcnQgc3BlZWQsIHRoZSBkdXBsZXggc2V0dGluZywgd2hldGhlciBsaW5rIGlzIGZvcmNl ZCB1cCwgZXRjLgoKTG9va2luZyBhdCB3aGF0IG10NzUzeF9waHlsaW5rX21hY19saW5rX3VwKCkg ZG9lczoKCjEuIGl0IHNldHMgUE1DUl9SWF9FTiB8IFBNQ1JfVFhfRU4gfCBQTUNSX0ZPUkNFX0xO Sy4KMi4gaXQgc2V0cyBQTUNSX0ZPUkNFX1NQRUVEXzEwMDAgaWYgc3BlZWQgd2FzIDEwMDBNYnBz LCBvciBpZiB1c2luZwogICBhbiBpbnRlcm5hbCwgVFJHTUlJLCAxMDAwYmFzZS1YIG9yIDI1MDBi YXNlLVggcGh5IGludGVyZmFjZSBtb2RlLgozLiBpdCBzZXRzIFBNQ1JfRk9SQ0VfRkRYIGlmIGZ1 bGwgZHVwbGV4IHdhcyByZXF1ZXN0ZWQuCjQuIGl0IHNldHMgUE1DUl9UWF9GQ19FTiBpZiBmdWxs IGR1cGxleCB3YXMgcmVxdWVzdGVkIHdpdGggdHggcGF1c2UuCjUuIGl0IHNldHMgUE1DUl9SWF9G Q19FTiBpZiBmdWxsIGR1cGxleCB3YXMgcmVxdWVzdGVkIHdpdGggcnggcGF1c2UuCgpTbywgcHJv dmlkZWQgdGhpcyBpcyBjYWxsZWQgd2l0aCB0aGUgYXBwcm9wcmlhdGUgcGFyYW1ldGVycywgZm9y IGEKZml4ZWQgbGluaywgdGhhdCB3aWxsIGxlYXZlIHRoZSBmb2xsb3dpbmc6CgoJUE1DUl9GT1JD RV9NT0RFX0lEKGlkKQoJUE1DUl9JRkdfWE1JVCgxKQoJUE1DUl9NQUNfTU9ERQoJUE1DUl9CQUNL T0ZGX0VOCglQTUNSX0JBQ0tQUl9FTgoKSWYgd2Ugbm93IGxvb2sgYXQgbXQ3NTN4X3BoeWxpbmtf bWFjX2NvbmZpZygpLCB0aGlzIHNldHMKUE1DUl9JRkdfWE1JVCgxKSwgUE1DUl9NQUNfTU9ERSwg UE1DUl9CQUNLT0ZGX0VOLCBQTUNSX0JBQ0tQUl9FTiwKYW5kIFBNQ1JfRk9SQ0VfTU9ERV9JRChw cml2LT5pZCksIHdoaWNoIEkgYmVsaWV2ZSBpcyBldmVyeXRoaW5nIHRoYXQKUE1DUl9DUFVfUE9S VF9TRVRUSU5HKHByaXYtPmlkKSBpcyBkb2luZy4KClNvLCBXb3VsZG4ndCBhIGZpeGVkLWxpbmsg ZGVzY3JpcHRpb24gaW5kaWNhdGluZyAxR2JwcywgZnVsbCBkdXBsZXgKd2l0aCBwYXVzZSBjYXVz ZSBwaHlsaW5rIHRvIGNhbGwgYm90aCBtdDc1M3hfcGh5bGlua19tYWNfY29uZmlnKCkgYW5kCm10 NzUzeF9waHlsaW5rX21hY19saW5rX3VwKCkgd2l0aCBhcHByb3ByaWF0ZSBhcmd1bWVudHMgdG8g c2V0IGFsbApvZiB0aGVzZSBwYXJhbWV0ZXJzIGluIFBNQ1I/CgpOb3csIEknbSBnb2luZyB0byBh bmFseXNlIHNvbWV0aGluZyBlbHNlLiBtdDc1MzFfY3B1X3BvcnRfY29uZmlnKCkKaXMgY2FsbGVk IGZyb20gbXQ3NTN4X2NwdV9wb3J0X2VuYWJsZSgpLCB3aGljaCBpcyBpdHNlbGYgY2FsbGVkIGZy b20KbXQ3NTMxX3NldHVwX2NvbW1vbigpLiBUaGF0IGlzIHVsdGltYXRlbHkgY2FsbGVkIGZyb20g dGhlIERTQSBzd2l0Y2gKb3BzIC5zZXR1cCgpIG1ldGhvZC4KClRoaXMgbWV0aG9kIGlzIGNhbGxl ZCBmcm9tIGRzYV9zd2l0Y2hfc2V0dXAoKSBmb3IgZWFjaCBzd2l0Y2ggaW4gdGhlCkRTQSB0cmVl LiBkc2FfdHJlZV9zZXR1cF9zd2l0Y2hlcygpIGNhbGxzIHRoaXMsIGFuZCBpcyBjYWxsZWQgZnJv bQpkc2FfdHJlZV9zZXR1cCgpLiAgT25jZSBkc2FfdHJlZV9zZXR1cF9zd2l0Y2hlcygpIGZpbmlz aGVzCnN1Y2Nlc3NmdWxseSwgZHNhX3RyZWVfc2V0dXBfcG9ydHMoKSB3aWxsIGJlIGNhbGxlZC4g VGhpcyB3aWxsIHRoZW4Kc2V0dXAgRFNBIGFuZCBDUFUgcG9ydHMsIHdoaWNoIHdpbGwgdGhlbiBz ZXR1cCBhIHBoeWxpbmsgaW5zdGFuY2UKZm9yIHRoZXNlIHBvcnRzLiBwaHlsaW5rIHdpbGwgcGFy c2UgdGhlIGZpcm13YXJlIGRlc2NyaXB0aW9uIGZvcgp0aGUgcG9ydC4gRFNBIHdpbGwgdGhlbiBj YWxsIGRzYV9wb3J0X2VuYWJsZSgpLgoKZHNhX3BvcnRfZW5hYmxlKCkgd2lsbCB0aGVuIGNhbGwg YW55IHBvcnRfZW5hYmxlKCkgbWV0aG9kIGluIHRoZQptdDc1MzAuYyBkcml2ZXIsIHdoaWNoIHdp bGwgYmUgbXQ3NTMwX3BvcnRfZW5hYmxlKCkuIFRoaXMgdGhlbi4uLgoKICAgICAgICBtdDc1MzBf Y2xlYXIocHJpdiwgTVQ3NTMwX1BNQ1JfUChwb3J0KSwgUE1DUl9MSU5LX1NFVFRJTkdTX01BU0sp OwoKd2hpY2ggaXM6CgojZGVmaW5lICBQTUNSX0xJTktfU0VUVElOR1NfTUFTSyAgICAgICAgKFBN Q1JfVFhfRU4gfCBQTUNSX0ZPUkNFX1NQRUVEXzEwMDAgfCBcCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgUE1DUl9SWF9FTiB8IFBNQ1JfRk9SQ0VfU1BFRURfMTAwIHwg XAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBNQ1JfVFhfRkNfRU4g fCBQTUNSX1JYX0ZDX0VOIHwgXAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFBNQ1JfRk9SQ0VfRkRYIHwgUE1DUl9GT1JDRV9MTksgfCBcCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgUE1DUl9GT1JDRV9FRUUxRyB8IFBNQ1JfRk9SQ0VfRUVF MTAwKQoKU28gaXQgd2lwZXMgb3V0IGFsbCB0aGUgUE1DUiBzZXR0aW5ncyB0aGF0IG10NzUzMV9j cHVfcG9ydF9jb25maWcoKQpwZXJmb3JtZWQgLSB1bmRvaW5nICpldmVyeXRoaW5nKiBiZWxvdyB0 aGF0IHN3aXRjaCgpIHN0YXRlbWVudCBpbgptdDc1MzFfY3B1X3BvcnRfY29uZmlnKCkhCgpPbmNl IHRoZSBwb3J0X2VuYWJsZSgpIG1ldGhvZCByZXR1cm5zLCBEU0Egd2lsbCB0aGVuIGNhbGwKcGh5 bGlua19zdGFydCgpLCB3aGljaCB3aWxsIHRyaWdnZXIgcGh5bGluayB0byBicmluZyB1cCB0aGUg bGluawphY2NvcmRpbmcgdG8gdGhlIHNldHRpbmdzIGl0IGhhcywgd2hpY2ggd2lsbCBtZWFuIHBo eWxpbmsgY2FsbHMKdGhlIG1hY19jb25maWcoKSwgcGNzX2NvbmZpZygpLCBwY3NfbGlua191cCgp IGFuZCBtYWNfbGlua191cCgpCndpdGggdGhlIGFwcHJvcHJpYXRlIHBhcmFtZXRlcnMgZm9yIHRo ZSBmaXJtd2FyZSBkZXNjcmliZWQgbGluay4KClNvIEkgdGhpbmsgSSBoYXZlIHRoZSBhbnN3ZXIg dG8gbXkgaW5pdGlhbCB0aG91Z2h0OiBkbyB0aGUgY2FsbHMgaW4KbXQ3NTMxX2NwdV9wb3J0X2Nv bmZpZygpIHRvIHRoZSBwaHlsaW5rIG1ldGhvZHMgaGF2ZSBhbnkgdXNlIHdoYXQgc28KZXZlcj8g VGhlIGFuc3dlciBpcyBubywgdGhleSBhcmUgZW50aXJlbHkgdXNlbGVzcy4gVGhlIHNhbWUgZ29l cyBmb3IKdGhlIG90aGVyIGNwdV9wb3J0X2NvbmZpZygpIG1ldGhvZHMgdGhhdCBkbyBzb21ldGhp bmcgc2ltaWxhci4gVGhlCnNhbWUgZ29lcyBmb3IgdGhlIFBNQ1IgcmVnaXN0ZXIgd3JpdGUgdGhh dCdzIGNoYW5naW5nIGFueSBiaXRzCmluY2x1ZGVkIGluIFBNQ1JfTElOS19TRVRUSU5HU19NQVNL LgoKV2hhdCB0aGF0IG1lYW5zIGlzIHRoYXQgbXQ3OTg4X2NwdV9wb3J0X2NvbmZpZygpIGNhbiBi ZSBlbnRpcmVseQpyZW1vdmVkLCBpdCBzZXJ2ZXMgbm8gdXNlZnVsIHB1cnBvc2Ugd2hhdCBzbyBl dmVyLiBGb3IKbXQ3NTMxX2NwdV9wb3J0X2NvbmZpZygpLCBpdCBvbmx5IG5lZWRzIHRvIHNldCBw cml2LT5wWzU2XV9pbnRlcmZhY2UKd2hpY2gsIGFzIGZhciBhcyBJIGNhbiBzZWUsIHByb2JhYmx5 IG9ubHkgYXZvaWRzIG1hY19jb25maWcoKSBkb2luZwphbnkgcGFkIHNldHVwICh0aGF0J3MgYSBn dWVzcy4pCgpBdCBsZWFzdCB0aGF0J3Mgd2hhdCBJIGdhdGhlciBmcm9tIHJlYWRpbmcgdGhyb3Vn aCB0aGUgZHJpdmVyIGFuZApEU0EgY29kZS4gSXQgbWF5IGJlIEkndmUgbWlzc2VkIHNvbWV0aGlu ZywgYnV0IGN1cnJlbnRseSwgSSB0aGluawp0aGF0IHRoZXNlIGNwdV9wb3J0X2NvbmZpZygpIGZ1 bmN0aW9ucyBhcmVuJ3QgZG9pbmcgdG9vIG11Y2ggdGhhdAppcyBhY3R1YWxseSB1c2VmdWwgd29y ay4KCi0tIApSTUsncyBQYXRjaCBzeXN0ZW06IGh0dHBzOi8vd3d3LmFybWxpbnV4Lm9yZy51ay9k ZXZlbG9wZXIvcGF0Y2hlcy8KRlRUUCBpcyBoZXJlISA4ME1icHMgZG93biAxME1icHMgdXAuIERl Y2VudCBjb25uZWN0aXZpdHkgYXQgbGFzdCEKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCmxpbnV4LWFybS1rZXJuZWwgbWFpbGluZyBsaXN0CmxpbnV4LWFy bS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFybS1rZXJuZWwK 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 E84A9C7EE29 for ; Sun, 4 Jun 2023 15:14:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229972AbjFDPOP (ORCPT ); Sun, 4 Jun 2023 11:14:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37706 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229449AbjFDPON (ORCPT ); Sun, 4 Jun 2023 11:14:13 -0400 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [IPv6:2001:4d48:ad52:32c8:5054:ff:fe00:142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A7277CA; Sun, 4 Jun 2023 08:14:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To: Content-Transfer-Encoding:Content-Type: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-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=bleTwqLDy63DUKjND0vhxknWwf9IMmoH1kBo/dk1g7E=; b=XC5ajlHrTHkMlFDqkqNWH1oZJY sVDDIMYBBA8B8P3k9AYiopTZhWhx9pehmlZA85PPrw4w234JrYGvdN8k5BcyQ/RWU9+yHjGPyzCph VgxT5vETval6ij6ANVR+7lAN1E0sMlEx02+a2vWs1/4E2EVZpsgbDQjAX2G+0I9nRXInMRh691k2t +duMlyG186mcHE3WUJyYUhi/HfQT6yE0sNRQNcK4D+By0iAyMROuEsxiQ9w8GihvOrxmfFl/gRDaL ubyr9R6elsjoSNlkVbKtqiynH8Z4t8e0G3cLToDhBgSVOksTEzw88n2qTH3F4p97QRF6J68DI6gPH Ym4G3sPQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:43062) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1q5pQU-0002iu-Uo; Sun, 04 Jun 2023 16:13:50 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1q5pQJ-0005A1-GU; Sun, 04 Jun 2023 16:13:39 +0100 Date: Sun, 4 Jun 2023 16:13:39 +0100 From: "Russell King (Oracle)" To: =?utf-8?B?QXLEsW7DpyDDnE5BTA==?= Cc: Vladimir Oltean , Sean Wang , Landen Chao , DENG Qingfang , Daniel Golle , Andrew Lunn , Florian Fainelli , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Matthias Brugger , AngeloGioacchino Del Regno , Richard van Schagen , Richard van Schagen , Frank Wunderlich , Bartel Eerdekens , erkin.bozoglu@xeront.com, mithat.guner@xeront.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org Subject: Re: [PATCH net-next 08/30] net: dsa: mt7530: change p{5,6}_interface to p{5,6}_configured Message-ID: References: <20230524175107.hwzygo7p4l4rvawj@skbuf> <576f92b0-1900-f6ff-e92d-4b82e3436ea1@arinc9.com> <20230526130145.7wg75yoe6ut4na7g@skbuf> <7117531f-a9f2-63eb-f69d-23267e5745d0@arinc9.com> <826fd2fc-fbf8-dab7-9c90-b726d15e2983@arinc9.com> <20230604125517.fwqh2uxzvsa7n5hu@skbuf> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: Russell King (Oracle) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jun 04, 2023 at 04:14:31PM +0300, Arınç ÜNAL wrote: > On 4.06.2023 16:07, Russell King (Oracle) wrote: > > On Sun, Jun 04, 2023 at 03:55:17PM +0300, Vladimir Oltean wrote: > > > On Sun, Jun 04, 2023 at 01:18:04PM +0100, Russell King (Oracle) wrote: > > > > I don't remember whether Vladimir's firmware validator will fail for > > > > mt753x if CPU ports are not fully described, but that would be well > > > > worth checking. If it does, then we can be confident that phylink > > > > will always be used, and those bypassing calls should not be necessary. > > > > > > It does, I've just retested this: > > > > > > [ 8.469152] mscc_felix 0000:00:00.5: OF node /soc/pcie@1f0000000/ethernet-switch@0,5/ports/port@4 of CPU port 4 lacks the required "phy-handle", "fixed-link" or "managed" properties > > > [ 8.494571] mscc_felix 0000:00:00.5: error -EINVAL: Failed to register DSA switch > > > [ 8.502151] mscc_felix: probe of 0000:00:00.5 failed with error -22 > > > > ... which isn't listed in dsa_switches_apply_workarounds[], and > > neither is mt753x. Thanks. > > > > So, that should be sufficient to know that the CPU port will always > > properly described, and thus bypassing phylink in mt753x for the CPU > > port should not be necessary. > > Perfect! If I understand correctly, there's this code - specific to MT7531 > and MT7988 ports being used as CPU ports - which runs in addition to what's > in mt753x_phylink_mac_config(): > > mt7530_write(priv, MT7530_PMCR_P(port), > PMCR_CPU_PORT_SETTING(priv->id)); > > This should be put on mt753x_phylink_mac_config(), under priv->id == > ID_MT7531, priv->id == ID_MT7988, and dsa_is_cpu_port(ds, port) checks? Please remember that I have very little knowledge of MT753x, so in order to answer this question, I've read through the mt7530 driver code. Looking at mt7530.h: #define PMCR_CPU_PORT_SETTING(id) (PMCR_FORCE_MODE_ID((id)) | \ PMCR_IFG_XMIT(1) | PMCR_MAC_MODE | \ PMCR_BACKOFF_EN | PMCR_BACKPR_EN | \ PMCR_TX_EN | PMCR_RX_EN | \ PMCR_TX_FC_EN | PMCR_RX_FC_EN | \ PMCR_FORCE_SPEED_1000 | \ PMCR_FORCE_FDX | PMCR_FORCE_LNK) This seems to be some kind of port control register that sets amongst other things parameters such as whether flow control is enabled, the port speed, the duplex setting, whether link is forced up, etc. Looking at what mt753x_phylink_mac_link_up() does: 1. it sets PMCR_RX_EN | PMCR_TX_EN | PMCR_FORCE_LNK. 2. it sets PMCR_FORCE_SPEED_1000 if speed was 1000Mbps, or if using an internal, TRGMII, 1000base-X or 2500base-X phy interface mode. 3. it sets PMCR_FORCE_FDX if full duplex was requested. 4. it sets PMCR_TX_FC_EN if full duplex was requested with tx pause. 5. it sets PMCR_RX_FC_EN if full duplex was requested with rx pause. So, provided this is called with the appropriate parameters, for a fixed link, that will leave the following: PMCR_FORCE_MODE_ID(id) PMCR_IFG_XMIT(1) PMCR_MAC_MODE PMCR_BACKOFF_EN PMCR_BACKPR_EN If we now look at mt753x_phylink_mac_config(), this sets PMCR_IFG_XMIT(1), PMCR_MAC_MODE, PMCR_BACKOFF_EN, PMCR_BACKPR_EN, and PMCR_FORCE_MODE_ID(priv->id), which I believe is everything that PMCR_CPU_PORT_SETTING(priv->id) is doing. So, Wouldn't a fixed-link description indicating 1Gbps, full duplex with pause cause phylink to call both mt753x_phylink_mac_config() and mt753x_phylink_mac_link_up() with appropriate arguments to set all of these parameters in PMCR? Now, I'm going to analyse something else. mt7531_cpu_port_config() is called from mt753x_cpu_port_enable(), which is itself called from mt7531_setup_common(). That is ultimately called from the DSA switch ops .setup() method. This method is called from dsa_switch_setup() for each switch in the DSA tree. dsa_tree_setup_switches() calls this, and is called from dsa_tree_setup(). Once dsa_tree_setup_switches() finishes successfully, dsa_tree_setup_ports() will be called. This will then setup DSA and CPU ports, which will then setup a phylink instance for these ports. phylink will parse the firmware description for the port. DSA will then call dsa_port_enable(). dsa_port_enable() will then call any port_enable() method in the mt7530.c driver, which will be mt7530_port_enable(). This then... mt7530_clear(priv, MT7530_PMCR_P(port), PMCR_LINK_SETTINGS_MASK); which is: #define PMCR_LINK_SETTINGS_MASK (PMCR_TX_EN | PMCR_FORCE_SPEED_1000 | \ PMCR_RX_EN | PMCR_FORCE_SPEED_100 | \ PMCR_TX_FC_EN | PMCR_RX_FC_EN | \ PMCR_FORCE_FDX | PMCR_FORCE_LNK | \ PMCR_FORCE_EEE1G | PMCR_FORCE_EEE100) So it wipes out all the PMCR settings that mt7531_cpu_port_config() performed - undoing *everything* below that switch() statement in mt7531_cpu_port_config()! Once the port_enable() method returns, DSA will then call phylink_start(), which will trigger phylink to bring up the link according to the settings it has, which will mean phylink calls the mac_config(), pcs_config(), pcs_link_up() and mac_link_up() with the appropriate parameters for the firmware described link. So I think I have the answer to my initial thought: do the calls in mt7531_cpu_port_config() to the phylink methods have any use what so ever? The answer is no, they are entirely useless. The same goes for the other cpu_port_config() methods that do something similar. The same goes for the PMCR register write that's changing any bits included in PMCR_LINK_SETTINGS_MASK. What that means is that mt7988_cpu_port_config() can be entirely removed, it serves no useful purpose what so ever. For mt7531_cpu_port_config(), it only needs to set priv->p[56]_interface which, as far as I can see, probably only avoids mac_config() doing any pad setup (that's a guess.) At least that's what I gather from reading through the driver and DSA code. It may be I've missed something, but currently, I think that these cpu_port_config() functions aren't doing too much that is actually useful work. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!