[PATCH 10/11] crypto: sun4i-ss: fix large block size support
Antoine Tenart
antoine.tenart at free-electrons.com
Mon May 29 01:09:44 PDT 2017
Hi Corentin,
On Fri, May 26, 2017 at 04:55:01PM +0200, Corentin Labbe wrote:
> On Wed, May 24, 2017 at 09:06:51PM +0200, Antoine Tenart wrote:
> >
> > + /*
> > + * The datasheet isn't very clear about when to retrieve the digest. The
> > + * bit SS_DATA_END is cleared when the engine has processed the data and
> > + * when the digest is computed *but* it doesn't mean the digest is
> > + * available in the diesgt registers. Hence the delay to be sure we can
>
> Small typo here (diesgt/digest)
Oops. I'll fix it.
> This behaviour is very strange since I didnt get it on other platform.
> Could you give me the board name where you get it ?
I used a CHIP (sun5i-r8-chip).
> Does any wmb() after the writel(..SS_DATA_END..) do the trick ?
Nope. I tried this and it didn't help.
> Which speed are the SS clocks ?
The AHB SS clk is running at 300 MHz and the SS clk at 150 MHz. SS clk
is at the expected rate but the AHB SS clk has a higher rate that what's
expected.
In the probing function only the SS clk rate is explicitly set. I tried
to set the AHB clk rate as well and removed the delays. This didn't fix
the framework selftests at boot time. Is there any reason the AHB SS clk
rate isn't explicitly set when probing the driver? (Should it?)
> Anyway the whole serie seems good, I will test it just after this weekend.
Let me know if your tests went well, I'll send a v2 fixing the typo
below then (and setting the AHB SS clk rate explicitly if needed).
Thanks,
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170529/0cc8ea33/attachment.sig>
More information about the linux-arm-kernel
mailing list