> -----Original Message-----
> From: linux-crypto-owner@xxxxxxxxxxxxxxx <linux-crypto-owner@xxxxxxxxxxxxxxx> On Behalf Of
> Antoine Tenart
> Sent: Monday, August 5, 2019 11:07 AM
> To: Pascal van Leeuwen <pascalvanl@xxxxxxxxx>
> Cc: linux-crypto@xxxxxxxxxxxxxxx; antoine.tenart@xxxxxxxxxxx; herbert@xxxxxxxxxxxxxxxxxxx;
> davem@xxxxxxxxxxxxx; Pascal Van Leeuwen <pvanleeuwen@xxxxxxxxxxxxxx>
> Subject: Re: [PATCHv3 4/4] crypto: inside-secure - add support for using the EIP197
> without vendor firmware
>
> Hi Pascal,
>
> Just a small comment below,
>
> On Wed, Jul 31, 2019 at 05:29:19PM +0200, Pascal van Leeuwen wrote:
> >
> > - /* Release engine from reset */
> > - val = readl(EIP197_PE(priv) + ctrl);
> > - val &= ~EIP197_PE_ICE_x_CTRL_SW_RESET;
> > - writel(val, EIP197_PE(priv) + ctrl);
> > + for (pe = 0; pe < priv->config.pes; pe++) {
> > + base = EIP197_PE_ICE_SCRATCH_RAM(pe);
> > + pollcnt = EIP197_FW_START_POLLCNT;
> > + while (pollcnt &&
> > + (readl_relaxed(EIP197_PE(priv) + base +
> > + pollofs) != 1)) {
> > + pollcnt--;
>
> You might want to use readl_relaxed_poll_timeout() here, instead of a
> busy polling.
>
Didn't know such a thing existed, but I also wonder how appropriate it
is in this case, condering it measures in whole microseconds, while the
response time I'm expecting here is in the order of a few dozen nano-
seconds internally ... i.e. 1 microsecond is already a *huge* overkill.
The current implementation runs that loop for only 16 iterations which
should be both more than sufficient (it probably could be reduced
further, I picked 16 rather arbitrarily) and at the same time take so
few cycles on the CPU that I doubt it is worthwhile to reschedule/
preempt/whatever?
>
> Thanks,
> Antoine
>
> --
> Antoine Ténart, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
www.insidesecure.com
