[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f8445beb-52a0-bcb8-f4fa-3decdfde09fc@foss.st.com>
Date: Tue, 12 Sep 2023 09:36:55 +0200
From: Gatien CHEVALLIER <gatien.chevallier@...s.st.com>
To: Herbert Xu <herbert@...dor.apana.org.au>
CC: Olivia Mackall <olivia@...enic.com>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
Lionel Debieve <lionel.debieve@...s.st.com>,
<linux-crypto@...r.kernel.org>, <devicetree@...r.kernel.org>,
<linux-stm32@...md-mailman.stormreply.com>,
<linux-arm-kernel@...ts.infradead.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 05/10] hwrng: stm32 - rework error handling in
stm32_rng_read()
Hello Herbert,
On 9/12/23 06:02, Herbert Xu wrote:
> On Fri, Sep 08, 2023 at 06:51:15PM +0200, Gatien Chevallier wrote:
>>
>> + if (WARN_ON(sr & RNG_SR_CEIS), "RNG clock too slow - %x\n", sr)
>
> Introducing an unconditional WARN_ON is not acceptable. If you
> really need it, make it WARN_ON_ONCE. But why does this need
> to be a WARN instead of dev_err?
>
> Cheers,
It was my mistake and not my intention to change the WARN_ON_ONCE to a
WARN_ON. I've already sent a V2 correcting this.
It was already a WARN_ON_ONCE on the first implementation of the driver.
This is not an unrecoverable error as it doesn't affect the quality of
the entropy delivered by the RNG. The output is just too slow. It's here
to warn the developer of an incorrect clock source setting.
Best regards,
Gatien
Powered by blists - more mailing lists