linux-kernel - Re: [PATCH v2] net: stmmac: Wait a bit for the reset to take effect

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f5ddf800df95cdce32637d41bc1539aed0a7b6f3.camel@redhat.com>
Date: Tue, 16 Jan 2024 13:22:26 +0100
From: Paolo Abeni <pabeni@...hat.com>
To: Bernd Edlinger <bernd.edlinger@...mail.de>, Alexandre Torgue
 <alexandre.torgue@...s.st.com>, Jose Abreu <joabreu@...opsys.com>, "David
 S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub
 Kicinski <kuba@...nel.org>,  Maxime Coquelin <mcoquelin.stm32@...il.com>,
 netdev@...r.kernel.org, linux-stm32@...md-mailman.stormreply.com, 
 linux-arm-kernel@...ts.infradead.org, "linux-kernel@...r.kernel.org"
 <linux-kernel@...r.kernel.org>, Jiri Pirko <jiri@...dia.com>, Andrew Morton
 <akpm@...ux-foundation.org>
Subject: Re: [PATCH v2] net: stmmac: Wait a bit for the reset to take effect

On Mon, 2024-01-15 at 20:21 +0100, Bernd Edlinger wrote:
> otherwise the synopsys_id value may be read out wrong,
> because the GMAC_VERSION register might still be in reset
> state, for at least 1 us after the reset is de-asserted.
> 
> Add a wait for 10 us before continuing to be on the safe side.
> 
> > From what have you got that delay value?
> 
> Just try and error, with very old linux versions and old gcc versions
> the synopsys_id was read out correctly most of the time (but not always),
> with recent linux versions and recnet gcc versions it was read out
> wrongly most of the time, but again not always.
> I don't have access to the VHDL code in question, so I cannot
> tell why it takes so long to get the correct values, I also do not
> have more than a few hardware samples, so I cannot tell how long
> this timeout must be in worst case.
> Experimentally I can tell that the register is read several times
> as zero immediately after the reset is de-asserted, also adding several
> no-ops is not enough, adding a printk is enough, also udelay(1) seems to
> be enough but I tried that not very often, and I have not access to many
> hardware samples to be 100% sure about the necessary delay.
> And since the udelay here is only executed once per device instance,
> it seems acceptable to delay the boot for 10 us.
> 
> BTW: my hardware's synopsys id is 0x37.
> 
> Signed-off-by: Bernd Edlinger <bernd.edlinger@...mail.de>
> 
> Reviewed-by: Jiri Pirko <jiri@...dia.com>

Please have a better look at the process documentation.

No empty lines are allowed in the tag area.

A fixes tag is requires, something alike:

Fixes: <blamed commit hash> ("<blamed commit title>")

A bisection is not strictly required, you just need to be reasonably
confident about the the culprit.

You need to include the relevant target tree into the subj prefix (in
this case 'net').

Please include in the recipients list the persons that provided
feedback on previous release (Serge is missing).

I'm unsure why/how Andrew landed in the recipients list!?!

Cheers,

Paolo