| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <9a7c29b51575083201b963638bdb9fa5@risingedge.co.za>
Date: Tue, 12 Mar 2024 17:25:59 +0200
From: Justin Swartz <justin.swartz@...ingedge.co.za>
To: Arınç ÜNAL <arinc.unal@...nc9.com>
Cc: Daniel Golle <daniel@...rotopia.org>, DENG Qingfang <dqfext@...il.com>,
Sean Wang <sean.wang@...iatek.com>, Andrew Lunn <andrew@...n.ch>, Florian
Fainelli <f.fainelli@...il.com>, Vladimir Oltean <olteanv@...il.com>, "David
S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub
Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Matthias
Brugger <matthias.bgg@...il.com>, AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH] net: dsa: mt7530: disable LEDs before reset
On 2024-03-12 16:06, Arınç ÜNAL wrote:
> On 12.03.2024 15:01, Justin Swartz wrote:
>> Arınç
>>
>> On 2024-03-12 04:41, Arınç ÜNAL wrote:
>>> Wouldn't it be a better idea to increase the delay between
>>> reset_control_assert() and reset_control_deassert(), and
>>> gpiod_set_value_cansleep(priv->reset, 0) and
>>> gpiod_set_value_cansleep(priv->reset, 1) instead of disabling the LED
>>> controller and delaying before reset?
>>
>> I've done some additional tests to see what the difference would be
>> between increasing the reset hold period vs. disabling the LEDs then
>> sleeping before reset.
>>
>>
>> I wanted to know:
>>
>> When an active link is present on Port 3 at boot, what are the
>> minimum, maximum and average periods between ESW_P3_LED_0
>> going low and the signal inversion that seems to co-incide with
>> reset_control_deassert() for each approach?
>>
>>
>> I created two patches:
>>
>> WITH INCREASED RESET DELAY
>>
>> As I submitted a patch that added an intended 1000 - 1100 usec delay
>> before reset, I thought it would be fair to increase the reset hold
>> period by the same value.
>>
>> ---%---
>> --- a/drivers/net/dsa/mt7530.c
>> +++ b/drivers/net/dsa/mt7530.c
>> @@ -2243,11 +2243,11 @@ mt7530_setup(struct dsa_switch *ds)
>> */
>> if (priv->mcm) {
>> reset_control_assert(priv->rstc);
>> - usleep_range(1000, 1100);
>> + usleep_range(2000, 2200);
>> reset_control_deassert(priv->rstc);
>> } else {
>> gpiod_set_value_cansleep(priv->reset, 0);
>> - usleep_range(1000, 1100);
>> + usleep_range(2000, 2200);
>> gpiod_set_value_cansleep(priv->reset, 1);
>> }
>> ---%---
>>
>>
>> DISABLE LEDS BEFORE RESET
>>
>> Reset hold period unchanged from the intended 1000 - 1100 usec.
>>
>> ---%---
>> --- 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
>> */
>> ---%---
>>
>>
>> I ran 20 tests per patch, applied exclusively. 40 tests in total.
>>
>> <-- ESW_P3_LED_0 Low Period before Reset Deassertion -->
>>
>> TEST WITH INCREASED RESET DELAY DISABLE LEDS BEFORE RESET
>> # (usec) (usec)
>> -------------------------------------------------------------------
>> 1 182 4790
>> 2 370 3470
>> 3 240 4635
>> 4 1475 4850
>> 5 70 4775
>> 6 2730 4575
>> 7 3180 4565
>> 8 265 5650
>> 9 270 4690
>> 10 1525 4450
>> 11 3210 4735
>> 12 120 4690
>> 13 185 4625
>> 14 305 7020
>> 15 2975 4720
>> 16 245 4675
>> 17 350 4740
>> 18 80 17920
>> 19 150 17665
>> 20 100 4620
>>
>> Min 70 3470
>> Max 3210 17920
>>
>> Mean 270 4720
-1s/ Mean/Median/
>> Avg 923.421 6161.579
>>
>>
>> Every test resulted in a 40MHz HT_XTAL_FSEL, but after seeing 70 usec
>> and 80 usec periods I wondered how many more tests it may take before
>> an 25MHz HT_XTAL_FSEL appears.
>>
>> I was also surprised by the 17920 usec and 17665 usec periods listed
>> under the DISABLED LEDS BEFORE RESET column. Nothing unusual seemed
>> to be happening, at least as far as the kernel message output was
>> concerned.
>>
>> What do you make of these results?
>
> What I see is setting ESW_P3_LED_0 low via reset assertion is much more
> efficient than doing so by setting the LED controller off. So I'd
> prefer
> increasing the delay between assertion and reassertion. For example,
> the
> Realtek DSA subdriver has a much more generous delay. 25ms after reset
> assertion [1].
>
> Looking at your results, 2000 - 2200 usec delay still seems too close,
> so
> let's agree on an amount that will ensure that boards in any
> circumstances
> will have these pins back to the bootstrapping configuration before
> reset
> deassertion. What about 5000 - 5100 usec?
TEST ESW_P3_LED_0 LOW PERIOD
# (usec)
----------------------------------
1 5410
2 5440
3 4375
4 5490
5 5475
6 4335
7 4370
8 5435
9 4205
10 4335
11 3750
12 3170
13 4395
14 4375
15 3515
16 4335
17 4220
18 4175
19 4175
20 4350
Min 3170
Max 5490
Median 4342.500
Avg 4466.500
Looks reasonable to me.
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/tree/drivers/net/dsa/realtek/rtl83xx.c#n205
>
> Arınç
Powered by blists - more mailing lists