On Thu, Mar 9, 2023 at 6:58 AM Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > On Wed, Mar 08, 2023 at 10:19:48PM +0100, Linus Walleij wrote: > > > > So now the driver is fixed from a Ux500 point of view. > > I think there is actually a nasty bug in it that may be hard to > trigger. > > The stm32 driver as it stands will write up to 256 bytes into > the FIFO which on the ux500 is limited to 64 bytes. We need to > change the fixed 256-byte size to be dependent on the hardware > type. Right so that is done implicitly by using a buffer of 256 bytes. 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)." The way I interpret it is that if you write 64 bytes (16 32bit words) the AHB bus will simply stall until the data is processed, so the writel() hangs there and then 66/82 bus cycles later it will continue. This isn't the prettiest from a system PoV, as it can stall interrupt handling and cause latency jitter, but it's not actually a bug. It's kind of similar to that user experience "bug" on x86 PCs where the sound starts breaking up if you have too intense graphics going on, because the bus is too busy so the sound FIFO goes empty. But I can certainly make a patch to shrink the buffer from 256 to 64 bytes on Ux500 if it's the right thing to do. Yours, Linus Walleij
