wait in atomic context for an i2c crypto device to finish its execution

wait in atomic context for an i2c crypto device to finish its execution

[Tudor Ambarus]

Hi, Herbert, all,

I need an advice. I'm writing a driver for a crypto device that
communicates over I2C. Reads and writes from/to the i2c device are
sequential, I use a lock to synchronize the requests.

There are no interrupts for the i2c client. Each request has to send
a command, to wait for an estimated time so that the device finishes to
execute the command and then to read the result.

The crypto requests can be in atomic context. The maximum execution time
of a command in my crypto device is 115 milliseconds. Using a spinlock
to synchronize the requests and udelay for waiting the device to finish
the execution will block the core for at least 115 milliseconds.
If someone floods me with requests in atomic context, the core will be
doomed.

As of now I see two possibilities when treating requests in atomic
context:
1. fallback to the software implementation and hope that it's faster
    than my hw. My device is capable of doing ecc privkey generation,
    ecdh and ecdsa.
2. use spinlock and udelay and block the core.

What would you advise me, how should I treat requests in atomic context?

Thanks,
ta

Re: wait in atomic context for an i2c crypto device to finish its execution

[Gilad Ben-Yossef]

On Thu, Jun 29, 2017 at 1:05 PM, Tudor Ambarus
<tudor.ambarus@microchip.com> wrote:
> Hi, Herbert, all,
>
> I need an advice. I'm writing a driver for a crypto device that
> communicates over I2C. Reads and writes from/to the i2c device are
> sequential, I use a lock to synchronize the requests.
>
> There are no interrupts for the i2c client. Each request has to send
> a command, to wait for an estimated time so that the device finishes to
> execute the command and then to read the result.
>
> The crypto requests can be in atomic context. The maximum execution time
> of a command in my crypto device is 115 milliseconds. Using a spinlock
> to synchronize the requests and udelay for waiting the device to finish
> the execution will block the core for at least 115 milliseconds.
> If someone floods me with requests in atomic context, the core will be
> doomed.
>
> As of now I see two possibilities when treating requests in atomic
> context:
> 1. fallback to the software implementation and hope that it's faster
>    than my hw. My device is capable of doing ecc privkey generation,
>    ecdh and ecdsa.
> 2. use spinlock and udelay and block the core.
>

Perhaps I missed something but it sounds like a classic case to use a
work queue:

Have the crypto request API post a work queue item and return with -EINPROGRESS
Run all interaction with the I2C device in a work item that has no
problem sleeping for as long as you need it.
Call the completion callback from the work item.

Unless I've missed something this should work.

Hope it helps,
Gilad

-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

Re: wait in atomic context for an i2c crypto device to finish its execution

[Tudor Ambarus]

On 29.06.2017 13:12, Gilad Ben-Yossef wrote:
> Perhaps I missed something but it sounds like a classic case to use a
> work queue:

Makes sense, thanks!
ta