linux-kernel - Re: [PATCH v2 3/6] hwrng: imx-rngc - use polling to detect end of self test

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] [day] [month] [year] [list]

Message-ID: <20230829185813.odjl3zqwshbgki4m@viti.kaiser.cx>
Date:   Tue, 29 Aug 2023 20:58:13 +0200
From:   Martin Kaiser <martin@...ser.cx>
To:     Alexander Stein <alexander.stein@...tq-group.com>
Cc:     Herbert Xu <herbert@...dor.apana.org.au>,
        linux-crypto@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 3/6] hwrng: imx-rngc - use polling to detect end of
 self test

Hi Alexander,

Alexander Stein (alexander.stein@...tq-group.com) wrote:

> I'm still not convinced that using polling is simpler. By using 
> readl_poll_timeout() you will also get an interrupt, the timer one. Why 
> exactly is using polling much (!) simpler?

it requires much less code in the driver.

> > The selftest should take approx. 450us. Keep the overhead to a minimum
> > by polling every 500us. (We've already lowered the timeout to 1.5ms.)

> I suppose these times only hold true for a specific peripheral clock 
> frequency. Is it guaranteed that this frequency is fixed?

Good point. The lowest possible peripheral clock frequency is half of
what I used for the calculations, i.e. 33.25MHz. That would double the
durations. Should be ok for the selftest. But for the initial seed, we'd
get into a region where readl_poll_timeout (usleep_range) does no longer
make sense.

> For using IRQ it's simpler, there is no guessing: you return once the self 
> test finished. The timeout is identical anyway.

I've looked at other callers of readl_poll_timeout. It seems that none
of them is called in a driver's probe function or uses an overall
timeout of 200ms.

I'll keep the interrupt + completion and resubmit the patches for
adjusting the timeouts.

Thanks,
Martin