From: Justin Swartz <justin.swartz@risingedge.co.za> To: "Arınç ÜNAL" <arinc.unal@arinc9.com>, "Daniel Golle" <daniel@makrotopia.org>, "DENG Qingfang" <dqfext@gmail.com>, "Sean Wang" <sean.wang@mediatek.com>, "Andrew Lunn" <andrew@lunn.ch>, "Florian Fainelli" <f.fainelli@gmail.com>, "Vladimir Oltean" <olteanv@gmail.com>, "David S. Miller" <davem@davemloft.net>, "Eric Dumazet" <edumazet@google.com>, "Jakub Kicinski" <kuba@kernel.org>, "Paolo Abeni" <pabeni@redhat.com>, "Matthias Brugger" <matthias.bgg@gmail.com>, "AngeloGioacchino Del Regno" <angelogioacchino.delregno@collabora.com> Cc: Justin Swartz <justin.swartz@risingedge.co.za>, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org Subject: [PATCH] net: dsa: mt7530: disable LEDs before reset Date: Tue, 5 Mar 2024 06:39:51 +0200 [thread overview] Message-ID: <20240305043952.21590-1-justin.swartz@risingedge.co.za> (raw) Disable LEDs just before resetting the MT7530 to avoid situations where the ESW_P4_LED_0 and ESW_P3_LED_0 pin states may cause an unintended external crystal frequency to be selected. The HT_XTAL_FSEL (External Crystal Frequency Selection) field of HWTRAP (the Hardware Trap register) stores a 2-bit value that represents the state of the ESW_P4_LED_0 and ESW_P4_LED_0 pins (seemingly) sampled just after the MT7530 has been reset, as: ESW_P4_LED_0 ESW_P3_LED_0 Frequency ----------------------------------------- 0 1 20MHz 1 0 40MHz 1 1 25MHz The value of HT_XTAL_FSEL is bootstrapped by pulling ESW_P4_LED_0 and ESW_P3_LED_0 up or down accordingly, but: if a 40MHz crystal has been selected and the ESW_P3_LED_0 pin is high during reset, or a 20MHz crystal has been selected and the ESW_P4_LED_0 pin is high during reset, then the value of HT_XTAL_FSEL will indicate that a 25MHz crystal is present. By default, the state of the LED pins is PHY controlled to reflect the link state. To illustrate, if a board has: 5 ports with active low LED control, and HT_XTAL_FSEL bootstrapped for 40MHz. When the MT7530 is powered up without any external connection, only the LED associated with Port 3 is illuminated as ESW_P3_LED_0 is low. In this state, directly after mt7530_setup()'s reset is performed, the HWTRAP register (0x7800) reflects the intended HT_XTAL_FSEL (HWTRAP bits 10:9) of 40MHz: mt7530-mdio mdio-bus:1f: mt7530_read: 00007800 == 00007dcf >>> bin(0x7dcf >> 9 & 0b11) '0b10' But if a cable is connected to Port 3 and the link is active before mt7530_setup()'s reset takes place, then HT_XTAL_FSEL seems to be set for 25MHz: mt7530-mdio mdio-bus:1f: mt7530_read: 00007800 == 00007fcf >>> bin(0x7fcf >> 9 & 0b11) '0b11' Once HT_XTAL_FSEL reflects 25MHz, none of the ports are functional until the MT7621 (or MT7530 itself) is reset. By disabling the LED pins just before reset, the chance of an unintended HT_XTAL_FSEL value is reduced. Signed-off-by: Justin Swartz <justin.swartz@risingedge.co.za> --- drivers/net/dsa/mt7530.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c index 3c1f65759..8fa113126 100644 --- a/drivers/net/dsa/mt7530.c +++ b/drivers/net/dsa/mt7530.c @@ -2238,6 +2238,12 @@ mt7530_setup(struct dsa_switch *ds) } } + /* Disable LEDs before reset to prevent the MT7530 sampling a + * potentially incorrect HT_XTAL_FSEL value. + */ + mt7530_write(priv, MT7530_LED_EN, 0); + usleep_range(1000, 1100); + /* Reset whole chip through gpio pin or memory-mapped registers for * different type of hardware */ --
WARNING: multiple messages have this Message-ID (diff)
From: Justin Swartz <justin.swartz@risingedge.co.za> To: "Arınç ÜNAL" <arinc.unal@arinc9.com>, "Daniel Golle" <daniel@makrotopia.org>, "DENG Qingfang" <dqfext@gmail.com>, "Sean Wang" <sean.wang@mediatek.com>, "Andrew Lunn" <andrew@lunn.ch>, "Florian Fainelli" <f.fainelli@gmail.com>, "Vladimir Oltean" <olteanv@gmail.com>, "David S. Miller" <davem@davemloft.net>, "Eric Dumazet" <edumazet@google.com>, "Jakub Kicinski" <kuba@kernel.org>, "Paolo Abeni" <pabeni@redhat.com>, "Matthias Brugger" <matthias.bgg@gmail.com>, "AngeloGioacchino Del Regno" <angelogioacchino.delregno@collabora.com> Cc: Justin Swartz <justin.swartz@risingedge.co.za>, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org Subject: [PATCH] net: dsa: mt7530: disable LEDs before reset Date: Tue, 5 Mar 2024 06:39:51 +0200 [thread overview] Message-ID: <20240305043952.21590-1-justin.swartz@risingedge.co.za> (raw) Disable LEDs just before resetting the MT7530 to avoid situations where the ESW_P4_LED_0 and ESW_P3_LED_0 pin states may cause an unintended external crystal frequency to be selected. The HT_XTAL_FSEL (External Crystal Frequency Selection) field of HWTRAP (the Hardware Trap register) stores a 2-bit value that represents the state of the ESW_P4_LED_0 and ESW_P4_LED_0 pins (seemingly) sampled just after the MT7530 has been reset, as: ESW_P4_LED_0 ESW_P3_LED_0 Frequency ----------------------------------------- 0 1 20MHz 1 0 40MHz 1 1 25MHz The value of HT_XTAL_FSEL is bootstrapped by pulling ESW_P4_LED_0 and ESW_P3_LED_0 up or down accordingly, but: if a 40MHz crystal has been selected and the ESW_P3_LED_0 pin is high during reset, or a 20MHz crystal has been selected and the ESW_P4_LED_0 pin is high during reset, then the value of HT_XTAL_FSEL will indicate that a 25MHz crystal is present. By default, the state of the LED pins is PHY controlled to reflect the link state. To illustrate, if a board has: 5 ports with active low LED control, and HT_XTAL_FSEL bootstrapped for 40MHz. When the MT7530 is powered up without any external connection, only the LED associated with Port 3 is illuminated as ESW_P3_LED_0 is low. In this state, directly after mt7530_setup()'s reset is performed, the HWTRAP register (0x7800) reflects the intended HT_XTAL_FSEL (HWTRAP bits 10:9) of 40MHz: mt7530-mdio mdio-bus:1f: mt7530_read: 00007800 == 00007dcf >>> bin(0x7dcf >> 9 & 0b11) '0b10' But if a cable is connected to Port 3 and the link is active before mt7530_setup()'s reset takes place, then HT_XTAL_FSEL seems to be set for 25MHz: mt7530-mdio mdio-bus:1f: mt7530_read: 00007800 == 00007fcf >>> bin(0x7fcf >> 9 & 0b11) '0b11' Once HT_XTAL_FSEL reflects 25MHz, none of the ports are functional until the MT7621 (or MT7530 itself) is reset. By disabling the LED pins just before reset, the chance of an unintended HT_XTAL_FSEL value is reduced. Signed-off-by: Justin Swartz <justin.swartz@risingedge.co.za> --- drivers/net/dsa/mt7530.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c index 3c1f65759..8fa113126 100644 --- a/drivers/net/dsa/mt7530.c +++ b/drivers/net/dsa/mt7530.c @@ -2238,6 +2238,12 @@ mt7530_setup(struct dsa_switch *ds) } } + /* Disable LEDs before reset to prevent the MT7530 sampling a + * potentially incorrect HT_XTAL_FSEL value. + */ + mt7530_write(priv, MT7530_LED_EN, 0); + usleep_range(1000, 1100); + /* Reset whole chip through gpio pin or memory-mapped registers for * different type of hardware */ -- _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2024-03-05 5:43 UTC|newest] Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-03-05 4:39 Justin Swartz [this message] 2024-03-05 4:39 ` [PATCH] net: dsa: mt7530: disable LEDs before reset Justin Swartz 2024-03-08 9:51 ` Arınç ÜNAL 2024-03-08 14:46 ` Daniel Golle 2024-03-08 14:46 ` Daniel Golle 2024-03-12 0:07 ` Justin Swartz 2024-03-12 0:07 ` Justin Swartz 2024-03-12 1:03 ` Andrew Lunn 2024-03-12 1:03 ` Andrew Lunn 2024-03-12 2:41 ` Arınç ÜNAL 2024-03-12 12:01 ` Justin Swartz 2024-03-12 12:01 ` Justin Swartz 2024-03-12 14:06 ` Arınç ÜNAL 2024-03-12 15:25 ` Justin Swartz 2024-03-12 15:25 ` Justin Swartz 2024-03-12 16:35 ` Justin Swartz 2024-03-12 16:35 ` Justin Swartz 2024-03-12 19:21 ` [PATCH] net: dsa: mt7530: increase reset hold time Justin Swartz 2024-03-12 19:21 ` Justin Swartz 2024-03-13 8:59 ` Arınç ÜNAL 2024-03-13 11:52 ` Justin Swartz 2024-03-13 11:52 ` Justin Swartz 2024-03-13 12:06 ` Arınç ÜNAL 2024-03-13 13:13 ` Justin Swartz 2024-03-13 13:13 ` Justin Swartz 2024-03-13 15:04 ` Arınç ÜNAL 2024-03-13 15:38 ` Justin Swartz 2024-03-13 15:38 ` Justin Swartz 2024-03-13 15:51 ` Arınç ÜNAL 2024-03-11 21:10 ` [PATCH] net: dsa: mt7530: disable LEDs before reset patchwork-bot+netdevbpf 2024-03-11 21:10 ` patchwork-bot+netdevbpf 2024-03-11 21:22 ` Arınç ÜNAL 2024-03-11 21:58 ` Jakub Kicinski 2024-03-11 21:58 ` Jakub Kicinski 2024-03-11 21:58 ` Daniel Golle 2024-03-11 21:58 ` Daniel Golle 2024-03-11 23:27 ` Arınç ÜNAL 2024-03-11 23:43 ` Daniel Golle 2024-03-11 23:43 ` Daniel Golle 2024-03-12 3:17 ` Arınç ÜNAL 2024-03-12 8:38 ` Arınç ÜNAL 2024-03-12 10:46 ` Paolo Abeni 2024-03-12 10:46 ` Paolo Abeni 2024-03-12 11:21 ` Arınç ÜNAL
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20240305043952.21590-1-justin.swartz@risingedge.co.za \ --to=justin.swartz@risingedge.co.za \ --cc=andrew@lunn.ch \ --cc=angelogioacchino.delregno@collabora.com \ --cc=arinc.unal@arinc9.com \ --cc=daniel@makrotopia.org \ --cc=davem@davemloft.net \ --cc=dqfext@gmail.com \ --cc=edumazet@google.com \ --cc=f.fainelli@gmail.com \ --cc=kuba@kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mediatek@lists.infradead.org \ --cc=matthias.bgg@gmail.com \ --cc=netdev@vger.kernel.org \ --cc=olteanv@gmail.com \ --cc=pabeni@redhat.com \ --cc=sean.wang@mediatek.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.