On Thu, Jun 29, 2017 at 1:05 PM, Tudor Ambarus <tudor.ambarus@xxxxxxxxxxxxx> 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
