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 99789C77B73 for ; Sun, 4 Jun 2023 16:07:06 +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=3OUxATfYl8ZN5l6qgZVR1LuysKVqRTNjYsPk18jqhKc=; b=Gl+iTzB/i/R/qxcPO8kQUp7fBM mWi1Jign8NhIXlaOEcYrXSOp5Kbd4V7S8raKgkiKAlCip/HP8TjMhSgVp3prRd/qhi2mByQSHtyli PvOGVQN88RO5hVGxVmpgpvyiOJaZP7t9A8u9wOu+xUOoAq5gc+DhJq8YYpx7MRdAUx47kAkC+z5vb JYGsAvAjNmvK7IYz9UjOtGAhCyThrqOOaHrbK8chAWBJIRnLgC+fvHj0Hc/PPcD0HDS7hMazeyHwY efMqHovgydOUfFq0Jy0zyOJOUpArQL/khsZ2GYA/hfwN5QOEnkGgHh2Cs1qbYArLPQz4Kp/AJjWB5 JclRxsxA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q5qFw-00CQTK-1D; Sun, 04 Jun 2023 16:07:00 +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 1q5qFr-00CQSQ-2n; Sun, 04 Jun 2023 16:06:57 +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=3OUxATfYl8ZN5l6qgZVR1LuysKVqRTNjYsPk18jqhKc=; b=1ov/WgLqcog5fY90id+eITKa6U K9a/bVdYZUI3ir9CehaZnXEIUNWlfbPpTG8V30H4lpNg2kexsIzRxsEY0vgYyoahYOnqKdYjPtXNb tGtsvaYE5oEaQAxdUWKxWYt895f1AtUW483oebCgkIdr5fiQU6n/2krIX5dv4tErc07iK+6loaPYu 5OgrM5bUeejQ2/6lqqb3QbfpIrNwtJkYO0hXegPvsxLe8JR5mxJuFGr41mACgP1UlPsB6QQ8ij9v+ seCwohkM0SxhHdi1gwRRQfqziljeOyCz259ilbTA0Wmnkfh13VPHf679cLV0Qb20XXGygVZdO9xgu j6KMVNkg==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:46988) 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 1q5qFc-0002m4-Qf; Sun, 04 Jun 2023 17:06:40 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1q5qFZ-0005Bo-Aq; Sun, 04 Jun 2023 17:06:37 +0100 Date: Sun, 4 Jun 2023 17:06:37 +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: <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_090656_047180_1F7C02B5 X-CRM114-Status: GOOD ( 52.22 ) 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 05:00:11PM +0100, Russell King (Oracle) wrote: > On Sun, Jun 04, 2023 at 04:13:39PM +0100, Russell King (Oracle) wrote: > > 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. > > Essentially, I think this change will have no effect at all on the > driver, because any effect this code has is totally undone when the > driver's port_enable() method is called: > > diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c > index 9bc54e1348cb..447e63d74e0c 100644 > --- a/drivers/net/dsa/mt7530.c > +++ b/drivers/net/dsa/mt7530.c > @@ -2859,8 +2859,6 @@ mt7531_cpu_port_config(struct dsa_switch *ds, int port) > { > struct mt7530_priv *priv = ds->priv; > phy_interface_t interface; > - int speed; > - int ret; > > switch (port) { > case 5: > @@ -2880,36 +2878,6 @@ mt7531_cpu_port_config(struct dsa_switch *ds, int port) > return -EINVAL; > } > > - if (interface == PHY_INTERFACE_MODE_2500BASEX) > - speed = SPEED_2500; > - else > - speed = SPEED_1000; > - > - ret = mt7531_mac_config(ds, port, MLO_AN_FIXED, interface); > - if (ret) > - return ret; > - mt7530_write(priv, MT7530_PMCR_P(port), > - PMCR_CPU_PORT_SETTING(priv->id)); > - mt753x_phylink_pcs_link_up(&priv->pcs[port].pcs, MLO_AN_FIXED, > - interface, speed, DUPLEX_FULL); > - mt753x_phylink_mac_link_up(ds, port, MLO_AN_FIXED, interface, NULL, > - speed, DUPLEX_FULL, true, true); > - > - return 0; > -} > - > -static int > -mt7988_cpu_port_config(struct dsa_switch *ds, int port) > -{ > - struct mt7530_priv *priv = ds->priv; > - > - mt7530_write(priv, MT7530_PMCR_P(port), > - PMCR_CPU_PORT_SETTING(priv->id)); > - > - mt753x_phylink_mac_link_up(ds, port, MLO_AN_FIXED, > - PHY_INTERFACE_MODE_INTERNAL, NULL, > - SPEED_10000, DUPLEX_FULL, true, true); > - > return 0; > } > > @@ -3165,7 +3133,6 @@ const struct mt753x_info mt753x_table[] = { > .phy_read_c45 = mt7531_ind_c45_phy_read, > .phy_write_c45 = mt7531_ind_c45_phy_write, > .pad_setup = mt7988_pad_setup, > - .cpu_port_config = mt7988_cpu_port_config, > .mac_port_get_caps = mt7988_mac_port_get_caps, > .mac_port_config = mt7988_mac_config, > }, ... and with that patch we can remove the definition of PMCR_CPU_PORT_SETTING() as well! There is one possibility why we may not be able to remove this code - whether there's something in this which requires the CPU port to be setup prior to something else. Only someone knowledgeable of the hardware, or who has the hardware in front and can test would be able to work that out. -- 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 84889C77B73 for ; Sun, 4 Jun 2023 16:07: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: 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=FLZoSME4RLU+ZPzFuXsD5ZW7Rpztm38mS3lwEGB3DdM=; b=ldNJIdHdLrTiUc XPaDs6pRmZchKWK4P6hl8pcDMKpxcKlHysxMnbnchx1ti4TTLDae6Kxe2SxyaICMmKf+wlL7Uqsa/ Qjz+6Z7EEKwa7htN5Xhl8xJ2Pwe7xHp1oUx5S+e1a879BLo8lv7P0PqW3Ga4Ry7LAo0veK6QcVaBp JdoCnlGT3DJdJjij8XeT+q33Xut+Vos6dI0n+0bRuB7EWUHVO4D0kaPGdJyk65liixizJmmmX/Yd5 yq5CS3XDcck1tM94usARzqZ9qlgMYiR/Yig5a12Vj8cbP0l2gC/t3MPKfdKu+eGjrKqTT4fb3bDrk 0bj9aiD2t2J0tMGCRU/A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q5qFv-00CQT4-2n; Sun, 04 Jun 2023 16:06:59 +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 1q5qFr-00CQSQ-2n; Sun, 04 Jun 2023 16:06:57 +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=3OUxATfYl8ZN5l6qgZVR1LuysKVqRTNjYsPk18jqhKc=; b=1ov/WgLqcog5fY90id+eITKa6U K9a/bVdYZUI3ir9CehaZnXEIUNWlfbPpTG8V30H4lpNg2kexsIzRxsEY0vgYyoahYOnqKdYjPtXNb tGtsvaYE5oEaQAxdUWKxWYt895f1AtUW483oebCgkIdr5fiQU6n/2krIX5dv4tErc07iK+6loaPYu 5OgrM5bUeejQ2/6lqqb3QbfpIrNwtJkYO0hXegPvsxLe8JR5mxJuFGr41mACgP1UlPsB6QQ8ij9v+ seCwohkM0SxhHdi1gwRRQfqziljeOyCz259ilbTA0Wmnkfh13VPHf679cLV0Qb20XXGygVZdO9xgu j6KMVNkg==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:46988) 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 1q5qFc-0002m4-Qf; Sun, 04 Jun 2023 17:06:40 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1q5qFZ-0005Bo-Aq; Sun, 04 Jun 2023 17:06:37 +0100 Date: Sun, 4 Jun 2023 17:06:37 +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: <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_090656_047180_1F7C02B5 X-CRM114-Status: GOOD ( 52.22 ) 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 T24gU3VuLCBKdW4gMDQsIDIwMjMgYXQgMDU6MDA6MTFQTSArMDEwMCwgUnVzc2VsbCBLaW5nIChP cmFjbGUpIHdyb3RlOgo+IE9uIFN1biwgSnVuIDA0LCAyMDIzIGF0IDA0OjEzOjM5UE0gKzAxMDAs IFJ1c3NlbGwgS2luZyAoT3JhY2xlKSB3cm90ZToKPiA+IE9uIFN1biwgSnVuIDA0LCAyMDIzIGF0 IDA0OjE0OjMxUE0gKzAzMDAsIEFyxLFuw6cgw5xOQUwgd3JvdGU6Cj4gPiA+IE9uIDQuMDYuMjAy MyAxNjowNywgUnVzc2VsbCBLaW5nIChPcmFjbGUpIHdyb3RlOgo+ID4gPiA+IE9uIFN1biwgSnVu IDA0LCAyMDIzIGF0IDAzOjU1OjE3UE0gKzAzMDAsIFZsYWRpbWlyIE9sdGVhbiB3cm90ZToKPiA+ ID4gPiA+IE9uIFN1biwgSnVuIDA0LCAyMDIzIGF0IDAxOjE4OjA0UE0gKzAxMDAsIFJ1c3NlbGwg S2luZyAoT3JhY2xlKSB3cm90ZToKPiA+ID4gPiA+ID4gSSBkb24ndCByZW1lbWJlciB3aGV0aGVy IFZsYWRpbWlyJ3MgZmlybXdhcmUgdmFsaWRhdG9yIHdpbGwgZmFpbCBmb3IKPiA+ID4gPiA+ID4g bXQ3NTN4IGlmIENQVSBwb3J0cyBhcmUgbm90IGZ1bGx5IGRlc2NyaWJlZCwgYnV0IHRoYXQgd291 bGQgYmUgd2VsbAo+ID4gPiA+ID4gPiB3b3J0aCBjaGVja2luZy4gSWYgaXQgZG9lcywgdGhlbiB3 ZSBjYW4gYmUgY29uZmlkZW50IHRoYXQgcGh5bGluawo+ID4gPiA+ID4gPiB3aWxsIGFsd2F5cyBi ZSB1c2VkLCBhbmQgdGhvc2UgYnlwYXNzaW5nIGNhbGxzIHNob3VsZCBub3QgYmUgbmVjZXNzYXJ5 Lgo+ID4gPiA+ID4gCj4gPiA+ID4gPiBJdCBkb2VzLCBJJ3ZlIGp1c3QgcmV0ZXN0ZWQgdGhpczoK PiA+ID4gPiA+IAo+ID4gPiA+ID4gWyAgICA4LjQ2OTE1Ml0gbXNjY19mZWxpeCAwMDAwOjAwOjAw LjU6IE9GIG5vZGUgL3NvYy9wY2llQDFmMDAwMDAwMC9ldGhlcm5ldC1zd2l0Y2hAMCw1L3BvcnRz L3BvcnRANCBvZiBDUFUgcG9ydCA0IGxhY2tzIHRoZSByZXF1aXJlZCAicGh5LWhhbmRsZSIsICJm aXhlZC1saW5rIiBvciAibWFuYWdlZCIgcHJvcGVydGllcwo+ID4gPiA+ID4gWyAgICA4LjQ5NDU3 MV0gbXNjY19mZWxpeCAwMDAwOjAwOjAwLjU6IGVycm9yIC1FSU5WQUw6IEZhaWxlZCB0byByZWdp c3RlciBEU0Egc3dpdGNoCj4gPiA+ID4gPiBbICAgIDguNTAyMTUxXSBtc2NjX2ZlbGl4OiBwcm9i ZSBvZiAwMDAwOjAwOjAwLjUgZmFpbGVkIHdpdGggZXJyb3IgLTIyCj4gPiA+ID4gCj4gPiA+ID4g Li4uIHdoaWNoIGlzbid0IGxpc3RlZCBpbiBkc2Ffc3dpdGNoZXNfYXBwbHlfd29ya2Fyb3VuZHNb XSwgYW5kCj4gPiA+ID4gbmVpdGhlciBpcyBtdDc1M3guIFRoYW5rcy4KPiA+ID4gPiAKPiA+ID4g PiBTbywgdGhhdCBzaG91bGQgYmUgc3VmZmljaWVudCB0byBrbm93IHRoYXQgdGhlIENQVSBwb3J0 IHdpbGwgYWx3YXlzCj4gPiA+ID4gcHJvcGVybHkgZGVzY3JpYmVkLCBhbmQgdGh1cyBieXBhc3Np bmcgcGh5bGluayBpbiBtdDc1M3ggZm9yIHRoZSBDUFUKPiA+ID4gPiBwb3J0IHNob3VsZCBub3Qg YmUgbmVjZXNzYXJ5Lgo+ID4gPiAKPiA+ID4gUGVyZmVjdCEgSWYgSSB1bmRlcnN0YW5kIGNvcnJl Y3RseSwgdGhlcmUncyB0aGlzIGNvZGUgLSBzcGVjaWZpYyB0byBNVDc1MzEKPiA+ID4gYW5kIE1U Nzk4OCBwb3J0cyBiZWluZyB1c2VkIGFzIENQVSBwb3J0cyAtIHdoaWNoIHJ1bnMgaW4gYWRkaXRp b24gdG8gd2hhdCdzCj4gPiA+IGluIG10NzUzeF9waHlsaW5rX21hY19jb25maWcoKToKPiA+ID4g Cj4gPiA+IAltdDc1MzBfd3JpdGUocHJpdiwgTVQ3NTMwX1BNQ1JfUChwb3J0KSwKPiA+ID4gCQkg ICAgIFBNQ1JfQ1BVX1BPUlRfU0VUVElORyhwcml2LT5pZCkpOwo+ID4gPiAKPiA+ID4gVGhpcyBz aG91bGQgYmUgcHV0IG9uIG10NzUzeF9waHlsaW5rX21hY19jb25maWcoKSwgdW5kZXIgcHJpdi0+ aWQgPT0KPiA+ID4gSURfTVQ3NTMxLCBwcml2LT5pZCA9PSBJRF9NVDc5ODgsIGFuZCBkc2FfaXNf Y3B1X3BvcnQoZHMsIHBvcnQpIGNoZWNrcz8KPiA+IAo+ID4gUGxlYXNlIHJlbWVtYmVyIHRoYXQg SSBoYXZlIHZlcnkgbGl0dGxlIGtub3dsZWRnZSBvZiBNVDc1M3gsIHNvIGluCj4gPiBvcmRlciB0 byBhbnN3ZXIgdGhpcyBxdWVzdGlvbiwgSSd2ZSByZWFkIHRocm91Z2ggdGhlIG10NzUzMCBkcml2 ZXIKPiA+IGNvZGUuCj4gPiAKPiA+IExvb2tpbmcgYXQgbXQ3NTMwLmg6Cj4gPiAKPiA+ICNkZWZp bmUgIFBNQ1JfQ1BVX1BPUlRfU0VUVElORyhpZCkgICAgICAoUE1DUl9GT1JDRV9NT0RFX0lEKChp ZCkpIHwgXAo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQTUNS X0lGR19YTUlUKDEpIHwgUE1DUl9NQUNfTU9ERSB8IFwKPiA+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgUE1DUl9CQUNLT0ZGX0VOIHwgUE1DUl9CQUNLUFJfRU4gfCBc Cj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBNQ1JfVFhfRU4g fCBQTUNSX1JYX0VOIHwgXAo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBQTUNSX1RYX0ZDX0VOIHwgUE1DUl9SWF9GQ19FTiB8IFwKPiA+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgUE1DUl9GT1JDRV9TUEVFRF8xMDAwIHwgXAo+ID4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQTUNSX0ZPUkNFX0ZEWCB8 IFBNQ1JfRk9SQ0VfTE5LKQo+ID4gCj4gPiBUaGlzIHNlZW1zIHRvIGJlIHNvbWUga2luZCBvZiBw b3J0IGNvbnRyb2wgcmVnaXN0ZXIgdGhhdCBzZXRzIGFtb25nc3QKPiA+IG90aGVyIHRoaW5ncyBw YXJhbWV0ZXJzIHN1Y2ggYXMgd2hldGhlciBmbG93IGNvbnRyb2wgaXMgZW5hYmxlZCwgdGhlCj4g PiBwb3J0IHNwZWVkLCB0aGUgZHVwbGV4IHNldHRpbmcsIHdoZXRoZXIgbGluayBpcyBmb3JjZWQg dXAsIGV0Yy4KPiA+IAo+ID4gTG9va2luZyBhdCB3aGF0IG10NzUzeF9waHlsaW5rX21hY19saW5r X3VwKCkgZG9lczoKPiA+IAo+ID4gMS4gaXQgc2V0cyBQTUNSX1JYX0VOIHwgUE1DUl9UWF9FTiB8 IFBNQ1JfRk9SQ0VfTE5LLgo+ID4gMi4gaXQgc2V0cyBQTUNSX0ZPUkNFX1NQRUVEXzEwMDAgaWYg c3BlZWQgd2FzIDEwMDBNYnBzLCBvciBpZiB1c2luZwo+ID4gICAgYW4gaW50ZXJuYWwsIFRSR01J SSwgMTAwMGJhc2UtWCBvciAyNTAwYmFzZS1YIHBoeSBpbnRlcmZhY2UgbW9kZS4KPiA+IDMuIGl0 IHNldHMgUE1DUl9GT1JDRV9GRFggaWYgZnVsbCBkdXBsZXggd2FzIHJlcXVlc3RlZC4KPiA+IDQu IGl0IHNldHMgUE1DUl9UWF9GQ19FTiBpZiBmdWxsIGR1cGxleCB3YXMgcmVxdWVzdGVkIHdpdGgg dHggcGF1c2UuCj4gPiA1LiBpdCBzZXRzIFBNQ1JfUlhfRkNfRU4gaWYgZnVsbCBkdXBsZXggd2Fz IHJlcXVlc3RlZCB3aXRoIHJ4IHBhdXNlLgo+ID4gCj4gPiBTbywgcHJvdmlkZWQgdGhpcyBpcyBj YWxsZWQgd2l0aCB0aGUgYXBwcm9wcmlhdGUgcGFyYW1ldGVycywgZm9yIGEKPiA+IGZpeGVkIGxp bmssIHRoYXQgd2lsbCBsZWF2ZSB0aGUgZm9sbG93aW5nOgo+ID4gCj4gPiAJUE1DUl9GT1JDRV9N T0RFX0lEKGlkKQo+ID4gCVBNQ1JfSUZHX1hNSVQoMSkKPiA+IAlQTUNSX01BQ19NT0RFCj4gPiAJ UE1DUl9CQUNLT0ZGX0VOCj4gPiAJUE1DUl9CQUNLUFJfRU4KPiA+IAo+ID4gSWYgd2Ugbm93IGxv b2sgYXQgbXQ3NTN4X3BoeWxpbmtfbWFjX2NvbmZpZygpLCB0aGlzIHNldHMKPiA+IFBNQ1JfSUZH X1hNSVQoMSksIFBNQ1JfTUFDX01PREUsIFBNQ1JfQkFDS09GRl9FTiwgUE1DUl9CQUNLUFJfRU4s Cj4gPiBhbmQgUE1DUl9GT1JDRV9NT0RFX0lEKHByaXYtPmlkKSwgd2hpY2ggSSBiZWxpZXZlIGlz IGV2ZXJ5dGhpbmcgdGhhdAo+ID4gUE1DUl9DUFVfUE9SVF9TRVRUSU5HKHByaXYtPmlkKSBpcyBk b2luZy4KPiA+IAo+ID4gU28sIFdvdWxkbid0IGEgZml4ZWQtbGluayBkZXNjcmlwdGlvbiBpbmRp Y2F0aW5nIDFHYnBzLCBmdWxsIGR1cGxleAo+ID4gd2l0aCBwYXVzZSBjYXVzZSBwaHlsaW5rIHRv IGNhbGwgYm90aCBtdDc1M3hfcGh5bGlua19tYWNfY29uZmlnKCkgYW5kCj4gPiBtdDc1M3hfcGh5 bGlua19tYWNfbGlua191cCgpIHdpdGggYXBwcm9wcmlhdGUgYXJndW1lbnRzIHRvIHNldCBhbGwK PiA+IG9mIHRoZXNlIHBhcmFtZXRlcnMgaW4gUE1DUj8KPiA+IAo+ID4gTm93LCBJJ20gZ29pbmcg dG8gYW5hbHlzZSBzb21ldGhpbmcgZWxzZS4gbXQ3NTMxX2NwdV9wb3J0X2NvbmZpZygpCj4gPiBp cyBjYWxsZWQgZnJvbSBtdDc1M3hfY3B1X3BvcnRfZW5hYmxlKCksIHdoaWNoIGlzIGl0c2VsZiBj YWxsZWQgZnJvbQo+ID4gbXQ3NTMxX3NldHVwX2NvbW1vbigpLiBUaGF0IGlzIHVsdGltYXRlbHkg Y2FsbGVkIGZyb20gdGhlIERTQSBzd2l0Y2gKPiA+IG9wcyAuc2V0dXAoKSBtZXRob2QuCj4gPiAK PiA+IFRoaXMgbWV0aG9kIGlzIGNhbGxlZCBmcm9tIGRzYV9zd2l0Y2hfc2V0dXAoKSBmb3IgZWFj aCBzd2l0Y2ggaW4gdGhlCj4gPiBEU0EgdHJlZS4gZHNhX3RyZWVfc2V0dXBfc3dpdGNoZXMoKSBj YWxscyB0aGlzLCBhbmQgaXMgY2FsbGVkIGZyb20KPiA+IGRzYV90cmVlX3NldHVwKCkuICBPbmNl IGRzYV90cmVlX3NldHVwX3N3aXRjaGVzKCkgZmluaXNoZXMKPiA+IHN1Y2Nlc3NmdWxseSwgZHNh X3RyZWVfc2V0dXBfcG9ydHMoKSB3aWxsIGJlIGNhbGxlZC4gVGhpcyB3aWxsIHRoZW4KPiA+IHNl dHVwIERTQSBhbmQgQ1BVIHBvcnRzLCB3aGljaCB3aWxsIHRoZW4gc2V0dXAgYSBwaHlsaW5rIGlu c3RhbmNlCj4gPiBmb3IgdGhlc2UgcG9ydHMuIHBoeWxpbmsgd2lsbCBwYXJzZSB0aGUgZmlybXdh cmUgZGVzY3JpcHRpb24gZm9yCj4gPiB0aGUgcG9ydC4gRFNBIHdpbGwgdGhlbiBjYWxsIGRzYV9w b3J0X2VuYWJsZSgpLgo+ID4gCj4gPiBkc2FfcG9ydF9lbmFibGUoKSB3aWxsIHRoZW4gY2FsbCBh bnkgcG9ydF9lbmFibGUoKSBtZXRob2QgaW4gdGhlCj4gPiBtdDc1MzAuYyBkcml2ZXIsIHdoaWNo IHdpbGwgYmUgbXQ3NTMwX3BvcnRfZW5hYmxlKCkuIFRoaXMgdGhlbi4uLgo+ID4gCj4gPiAgICAg ICAgIG10NzUzMF9jbGVhcihwcml2LCBNVDc1MzBfUE1DUl9QKHBvcnQpLCBQTUNSX0xJTktfU0VU VElOR1NfTUFTSyk7Cj4gPiAKPiA+IHdoaWNoIGlzOgo+ID4gCj4gPiAjZGVmaW5lICBQTUNSX0xJ TktfU0VUVElOR1NfTUFTSyAgICAgICAgKFBNQ1JfVFhfRU4gfCBQTUNSX0ZPUkNFX1NQRUVEXzEw MDAgfCBcCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBNQ1Jf UlhfRU4gfCBQTUNSX0ZPUkNFX1NQRUVEXzEwMCB8IFwKPiA+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgUE1DUl9UWF9GQ19FTiB8IFBNQ1JfUlhfRkNfRU4gfCBcCj4g PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBNQ1JfRk9SQ0VfRkRY IHwgUE1DUl9GT1JDRV9MTksgfCBcCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFBNQ1JfRk9SQ0VfRUVFMUcgfCBQTUNSX0ZPUkNFX0VFRTEwMCkKPiA+IAo+ID4g U28gaXQgd2lwZXMgb3V0IGFsbCB0aGUgUE1DUiBzZXR0aW5ncyB0aGF0IG10NzUzMV9jcHVfcG9y dF9jb25maWcoKQo+ID4gcGVyZm9ybWVkIC0gdW5kb2luZyAqZXZlcnl0aGluZyogYmVsb3cgdGhh dCBzd2l0Y2goKSBzdGF0ZW1lbnQgaW4KPiA+IG10NzUzMV9jcHVfcG9ydF9jb25maWcoKSEKPiA+ IAo+ID4gT25jZSB0aGUgcG9ydF9lbmFibGUoKSBtZXRob2QgcmV0dXJucywgRFNBIHdpbGwgdGhl biBjYWxsCj4gPiBwaHlsaW5rX3N0YXJ0KCksIHdoaWNoIHdpbGwgdHJpZ2dlciBwaHlsaW5rIHRv IGJyaW5nIHVwIHRoZSBsaW5rCj4gPiBhY2NvcmRpbmcgdG8gdGhlIHNldHRpbmdzIGl0IGhhcywg d2hpY2ggd2lsbCBtZWFuIHBoeWxpbmsgY2FsbHMKPiA+IHRoZSBtYWNfY29uZmlnKCksIHBjc19j b25maWcoKSwgcGNzX2xpbmtfdXAoKSBhbmQgbWFjX2xpbmtfdXAoKQo+ID4gd2l0aCB0aGUgYXBw cm9wcmlhdGUgcGFyYW1ldGVycyBmb3IgdGhlIGZpcm13YXJlIGRlc2NyaWJlZCBsaW5rLgo+ID4g Cj4gPiBTbyBJIHRoaW5rIEkgaGF2ZSB0aGUgYW5zd2VyIHRvIG15IGluaXRpYWwgdGhvdWdodDog ZG8gdGhlIGNhbGxzIGluCj4gPiBtdDc1MzFfY3B1X3BvcnRfY29uZmlnKCkgdG8gdGhlIHBoeWxp bmsgbWV0aG9kcyBoYXZlIGFueSB1c2Ugd2hhdCBzbwo+ID4gZXZlcj8gVGhlIGFuc3dlciBpcyBu bywgdGhleSBhcmUgZW50aXJlbHkgdXNlbGVzcy4gVGhlIHNhbWUgZ29lcyBmb3IKPiA+IHRoZSBv dGhlciBjcHVfcG9ydF9jb25maWcoKSBtZXRob2RzIHRoYXQgZG8gc29tZXRoaW5nIHNpbWlsYXIu IFRoZQo+ID4gc2FtZSBnb2VzIGZvciB0aGUgUE1DUiByZWdpc3RlciB3cml0ZSB0aGF0J3MgY2hh bmdpbmcgYW55IGJpdHMKPiA+IGluY2x1ZGVkIGluIFBNQ1JfTElOS19TRVRUSU5HU19NQVNLLgo+ ID4gCj4gPiBXaGF0IHRoYXQgbWVhbnMgaXMgdGhhdCBtdDc5ODhfY3B1X3BvcnRfY29uZmlnKCkg Y2FuIGJlIGVudGlyZWx5Cj4gPiByZW1vdmVkLCBpdCBzZXJ2ZXMgbm8gdXNlZnVsIHB1cnBvc2Ug d2hhdCBzbyBldmVyLiBGb3IKPiA+IG10NzUzMV9jcHVfcG9ydF9jb25maWcoKSwgaXQgb25seSBu ZWVkcyB0byBzZXQgcHJpdi0+cFs1Nl1faW50ZXJmYWNlCj4gPiB3aGljaCwgYXMgZmFyIGFzIEkg Y2FuIHNlZSwgcHJvYmFibHkgb25seSBhdm9pZHMgbWFjX2NvbmZpZygpIGRvaW5nCj4gPiBhbnkg cGFkIHNldHVwICh0aGF0J3MgYSBndWVzcy4pCj4gPiAKPiA+IEF0IGxlYXN0IHRoYXQncyB3aGF0 IEkgZ2F0aGVyIGZyb20gcmVhZGluZyB0aHJvdWdoIHRoZSBkcml2ZXIgYW5kCj4gPiBEU0EgY29k ZS4gSXQgbWF5IGJlIEkndmUgbWlzc2VkIHNvbWV0aGluZywgYnV0IGN1cnJlbnRseSwgSSB0aGlu awo+ID4gdGhhdCB0aGVzZSBjcHVfcG9ydF9jb25maWcoKSBmdW5jdGlvbnMgYXJlbid0IGRvaW5n IHRvbyBtdWNoIHRoYXQKPiA+IGlzIGFjdHVhbGx5IHVzZWZ1bCB3b3JrLgo+IAo+IEVzc2VudGlh bGx5LCBJIHRoaW5rIHRoaXMgY2hhbmdlIHdpbGwgaGF2ZSBubyBlZmZlY3QgYXQgYWxsIG9uIHRo ZQo+IGRyaXZlciwgYmVjYXVzZSBhbnkgZWZmZWN0IHRoaXMgY29kZSBoYXMgaXMgdG90YWxseSB1 bmRvbmUgd2hlbiB0aGUKPiBkcml2ZXIncyBwb3J0X2VuYWJsZSgpIG1ldGhvZCBpcyBjYWxsZWQ6 Cj4gCj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvbmV0L2RzYS9tdDc1MzAuYyBiL2RyaXZlcnMvbmV0 L2RzYS9tdDc1MzAuYwo+IGluZGV4IDliYzU0ZTEzNDhjYi4uNDQ3ZTYzZDc0ZTBjIDEwMDY0NAo+ IC0tLSBhL2RyaXZlcnMvbmV0L2RzYS9tdDc1MzAuYwo+ICsrKyBiL2RyaXZlcnMvbmV0L2RzYS9t dDc1MzAuYwo+IEBAIC0yODU5LDggKzI4NTksNiBAQCBtdDc1MzFfY3B1X3BvcnRfY29uZmlnKHN0 cnVjdCBkc2Ffc3dpdGNoICpkcywgaW50IHBvcnQpCj4gIHsKPiAgCXN0cnVjdCBtdDc1MzBfcHJp diAqcHJpdiA9IGRzLT5wcml2Owo+ICAJcGh5X2ludGVyZmFjZV90IGludGVyZmFjZTsKPiAtCWlu dCBzcGVlZDsKPiAtCWludCByZXQ7Cj4gIAo+ICAJc3dpdGNoIChwb3J0KSB7Cj4gIAljYXNlIDU6 Cj4gQEAgLTI4ODAsMzYgKzI4NzgsNiBAQCBtdDc1MzFfY3B1X3BvcnRfY29uZmlnKHN0cnVjdCBk c2Ffc3dpdGNoICpkcywgaW50IHBvcnQpCj4gIAkJcmV0dXJuIC1FSU5WQUw7Cj4gIAl9Cj4gIAo+ IC0JaWYgKGludGVyZmFjZSA9PSBQSFlfSU5URVJGQUNFX01PREVfMjUwMEJBU0VYKQo+IC0JCXNw ZWVkID0gU1BFRURfMjUwMDsKPiAtCWVsc2UKPiAtCQlzcGVlZCA9IFNQRUVEXzEwMDA7Cj4gLQo+ IC0JcmV0ID0gbXQ3NTMxX21hY19jb25maWcoZHMsIHBvcnQsIE1MT19BTl9GSVhFRCwgaW50ZXJm YWNlKTsKPiAtCWlmIChyZXQpCj4gLQkJcmV0dXJuIHJldDsKPiAtCW10NzUzMF93cml0ZShwcml2 LCBNVDc1MzBfUE1DUl9QKHBvcnQpLAo+IC0JCSAgICAgUE1DUl9DUFVfUE9SVF9TRVRUSU5HKHBy aXYtPmlkKSk7Cj4gLQltdDc1M3hfcGh5bGlua19wY3NfbGlua191cCgmcHJpdi0+cGNzW3BvcnRd LnBjcywgTUxPX0FOX0ZJWEVELAo+IC0JCQkJICAgaW50ZXJmYWNlLCBzcGVlZCwgRFVQTEVYX0ZV TEwpOwo+IC0JbXQ3NTN4X3BoeWxpbmtfbWFjX2xpbmtfdXAoZHMsIHBvcnQsIE1MT19BTl9GSVhF RCwgaW50ZXJmYWNlLCBOVUxMLAo+IC0JCQkJICAgc3BlZWQsIERVUExFWF9GVUxMLCB0cnVlLCB0 cnVlKTsKPiAtCj4gLQlyZXR1cm4gMDsKPiAtfQo+IC0KPiAtc3RhdGljIGludAo+IC1tdDc5ODhf Y3B1X3BvcnRfY29uZmlnKHN0cnVjdCBkc2Ffc3dpdGNoICpkcywgaW50IHBvcnQpCj4gLXsKPiAt CXN0cnVjdCBtdDc1MzBfcHJpdiAqcHJpdiA9IGRzLT5wcml2Owo+IC0KPiAtCW10NzUzMF93cml0 ZShwcml2LCBNVDc1MzBfUE1DUl9QKHBvcnQpLAo+IC0JCSAgICAgUE1DUl9DUFVfUE9SVF9TRVRU SU5HKHByaXYtPmlkKSk7Cj4gLQo+IC0JbXQ3NTN4X3BoeWxpbmtfbWFjX2xpbmtfdXAoZHMsIHBv cnQsIE1MT19BTl9GSVhFRCwKPiAtCQkJCSAgIFBIWV9JTlRFUkZBQ0VfTU9ERV9JTlRFUk5BTCwg TlVMTCwKPiAtCQkJCSAgIFNQRUVEXzEwMDAwLCBEVVBMRVhfRlVMTCwgdHJ1ZSwgdHJ1ZSk7Cj4g LQo+ICAJcmV0dXJuIDA7Cj4gIH0KPiAgCj4gQEAgLTMxNjUsNyArMzEzMyw2IEBAIGNvbnN0IHN0 cnVjdCBtdDc1M3hfaW5mbyBtdDc1M3hfdGFibGVbXSA9IHsKPiAgCQkucGh5X3JlYWRfYzQ1ID0g bXQ3NTMxX2luZF9jNDVfcGh5X3JlYWQsCj4gIAkJLnBoeV93cml0ZV9jNDUgPSBtdDc1MzFfaW5k X2M0NV9waHlfd3JpdGUsCj4gIAkJLnBhZF9zZXR1cCA9IG10Nzk4OF9wYWRfc2V0dXAsCj4gLQkJ LmNwdV9wb3J0X2NvbmZpZyA9IG10Nzk4OF9jcHVfcG9ydF9jb25maWcsCj4gIAkJLm1hY19wb3J0 X2dldF9jYXBzID0gbXQ3OTg4X21hY19wb3J0X2dldF9jYXBzLAo+ICAJCS5tYWNfcG9ydF9jb25m aWcgPSBtdDc5ODhfbWFjX2NvbmZpZywKPiAgCX0sCgouLi4gYW5kIHdpdGggdGhhdCBwYXRjaCB3 ZSBjYW4gcmVtb3ZlIHRoZSBkZWZpbml0aW9uIG9mClBNQ1JfQ1BVX1BPUlRfU0VUVElORygpIGFz IHdlbGwhCgpUaGVyZSBpcyBvbmUgcG9zc2liaWxpdHkgd2h5IHdlIG1heSBub3QgYmUgYWJsZSB0 byByZW1vdmUgdGhpcyBjb2RlIC0Kd2hldGhlciB0aGVyZSdzIHNvbWV0aGluZyBpbiB0aGlzIHdo aWNoIHJlcXVpcmVzIHRoZSBDUFUgcG9ydCB0byBiZQpzZXR1cCBwcmlvciB0byBzb21ldGhpbmcg ZWxzZS4gT25seSBzb21lb25lIGtub3dsZWRnZWFibGUgb2YgdGhlCmhhcmR3YXJlLCBvciB3aG8g aGFzIHRoZSBoYXJkd2FyZSBpbiBmcm9udCBhbmQgY2FuIHRlc3Qgd291bGQgYmUgYWJsZQp0byB3 b3JrIHRoYXQgb3V0LgoKLS0gClJNSydzIFBhdGNoIHN5c3RlbTogaHR0cHM6Ly93d3cuYXJtbGlu dXgub3JnLnVrL2RldmVsb3Blci9wYXRjaGVzLwpGVFRQIGlzIGhlcmUhIDgwTWJwcyBkb3duIDEw TWJwcyB1cC4gRGVjZW50IGNvbm5lY3Rpdml0eSBhdCBsYXN0IQoKX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGludXgtYXJtLWtlcm5lbCBtYWlsaW5nIGxp c3QKbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZy YWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtYXJtLWtlcm5lbAo= 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 3E095C77B73 for ; Sun, 4 Jun 2023 16:06:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231313AbjFDQG6 (ORCPT ); Sun, 4 Jun 2023 12:06:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46548 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229449AbjFDQGz (ORCPT ); Sun, 4 Jun 2023 12:06:55 -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 71D80B3; Sun, 4 Jun 2023 09:06:54 -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=3OUxATfYl8ZN5l6qgZVR1LuysKVqRTNjYsPk18jqhKc=; b=1ov/WgLqcog5fY90id+eITKa6U K9a/bVdYZUI3ir9CehaZnXEIUNWlfbPpTG8V30H4lpNg2kexsIzRxsEY0vgYyoahYOnqKdYjPtXNb tGtsvaYE5oEaQAxdUWKxWYt895f1AtUW483oebCgkIdr5fiQU6n/2krIX5dv4tErc07iK+6loaPYu 5OgrM5bUeejQ2/6lqqb3QbfpIrNwtJkYO0hXegPvsxLe8JR5mxJuFGr41mACgP1UlPsB6QQ8ij9v+ seCwohkM0SxhHdi1gwRRQfqziljeOyCz259ilbTA0Wmnkfh13VPHf679cLV0Qb20XXGygVZdO9xgu j6KMVNkg==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:46988) 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 1q5qFc-0002m4-Qf; Sun, 04 Jun 2023 17:06:40 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1q5qFZ-0005Bo-Aq; Sun, 04 Jun 2023 17:06:37 +0100 Date: Sun, 4 Jun 2023 17:06:37 +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: <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 05:00:11PM +0100, Russell King (Oracle) wrote: > On Sun, Jun 04, 2023 at 04:13:39PM +0100, Russell King (Oracle) wrote: > > 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. > > Essentially, I think this change will have no effect at all on the > driver, because any effect this code has is totally undone when the > driver's port_enable() method is called: > > diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c > index 9bc54e1348cb..447e63d74e0c 100644 > --- a/drivers/net/dsa/mt7530.c > +++ b/drivers/net/dsa/mt7530.c > @@ -2859,8 +2859,6 @@ mt7531_cpu_port_config(struct dsa_switch *ds, int port) > { > struct mt7530_priv *priv = ds->priv; > phy_interface_t interface; > - int speed; > - int ret; > > switch (port) { > case 5: > @@ -2880,36 +2878,6 @@ mt7531_cpu_port_config(struct dsa_switch *ds, int port) > return -EINVAL; > } > > - if (interface == PHY_INTERFACE_MODE_2500BASEX) > - speed = SPEED_2500; > - else > - speed = SPEED_1000; > - > - ret = mt7531_mac_config(ds, port, MLO_AN_FIXED, interface); > - if (ret) > - return ret; > - mt7530_write(priv, MT7530_PMCR_P(port), > - PMCR_CPU_PORT_SETTING(priv->id)); > - mt753x_phylink_pcs_link_up(&priv->pcs[port].pcs, MLO_AN_FIXED, > - interface, speed, DUPLEX_FULL); > - mt753x_phylink_mac_link_up(ds, port, MLO_AN_FIXED, interface, NULL, > - speed, DUPLEX_FULL, true, true); > - > - return 0; > -} > - > -static int > -mt7988_cpu_port_config(struct dsa_switch *ds, int port) > -{ > - struct mt7530_priv *priv = ds->priv; > - > - mt7530_write(priv, MT7530_PMCR_P(port), > - PMCR_CPU_PORT_SETTING(priv->id)); > - > - mt753x_phylink_mac_link_up(ds, port, MLO_AN_FIXED, > - PHY_INTERFACE_MODE_INTERNAL, NULL, > - SPEED_10000, DUPLEX_FULL, true, true); > - > return 0; > } > > @@ -3165,7 +3133,6 @@ const struct mt753x_info mt753x_table[] = { > .phy_read_c45 = mt7531_ind_c45_phy_read, > .phy_write_c45 = mt7531_ind_c45_phy_write, > .pad_setup = mt7988_pad_setup, > - .cpu_port_config = mt7988_cpu_port_config, > .mac_port_get_caps = mt7988_mac_port_get_caps, > .mac_port_config = mt7988_mac_config, > }, ... and with that patch we can remove the definition of PMCR_CPU_PORT_SETTING() as well! There is one possibility why we may not be able to remove this code - whether there's something in this which requires the CPU port to be setup prior to something else. Only someone knowledgeable of the hardware, or who has the hardware in front and can test would be able to work that out. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!