[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdZZ8ZoKjo-inJi7pwxF8FvfVn_ow1rgo0gdMCnok7ZmCw@mail.gmail.com>
Date: Fri, 10 Mar 2023 09:07:04 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: David Laight <David.Laight@...lab.com>
Cc: Herbert Xu <herbert@...dor.apana.org.au>,
Lionel Debieve <lionel.debieve@...s.st.com>,
Li kunyu <kunyu@...china.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-stm32@...md-mailman.stormreply.com"
<linux-stm32@...md-mailman.stormreply.com>,
"mcoquelin.stm32@...il.com" <mcoquelin.stm32@...il.com>
Subject: Re: [v5 PATCH 7/7] crypto: stm32 - Save and restore between each request
On Thu, Mar 9, 2023 at 11:19 PM David Laight <David.Laight@...lab.com> wrote:
> > But actually I think the bug will never trigger, because the datasheet
> > for the DB8500 (Ux500) says this:
> >
> > "Then the message can be sent, by writing it word per word into the
> > HASH_DIN register.
> > When a block of 512 bits, i.e. 16 words have been written, a partial
> > digest computation will
> > start upon writing the first data of the next block. The AHB bus will
> > be busy for 82 cycles for
> > SHA-1 algorithm (66 cycles for SHA-256 algorithm)."
>
> What speed clock is that?
133 MHz.
> 4 or 5 extra clocks/word may (or may not) be significant.
>
> In terms of latency it may be noise compared to some PCIe
> reads done by hardware interrupt handlers.
> Some slow PCIe targets (like the fpga one we use) pretty
> much take 1us to handle a read cycle.
So in this case it's 1/133M s = 8ns cycle time, 82 in worst case,
so 82*8 = 656 ns < 1 us.
Yours,
Linus Walleij
Powered by blists - more mailing lists