On Tue, Nov 11, 2014 at 08:04:03PM +0200, Nicolae Rosia wrote:
> On Fri, May 30, 2014 at 4:41 PM, Herbert Xu
> wrote:
>
> > [...]
> > This is because the user is supposed to back off once they get
> > EBUSY, until they're notified once the backlog entry is popped
> > off (but not processed, it mu
On Fri, May 30, 2014 at 01:33:06PM +, Hsieh, Che-Min wrote:
>
> It is nice to know that the request queue is per tfm. We are currently on
> android-3.10. I believe all the drivers under drivers/crypto/ don't follow
> this rule. At the minimum, our driver qcrypto does not. Other than
>
telis Antoniou
Subject: Re: [QUESTION] Crypto queue handling
On Mon, May 26, 2014 at 05:58:19PM +0200, Marek Vasut wrote:
> Hello,
>
> I'm digging in crypto/algapi.c , in the crypto_enqueue_request()
> function. I don't quite understand how the backlog mechanism should
On Mon, May 26, 2014 at 06:16:58PM +0200, Marek Vasut wrote:
>
> So, we call backlog->complete() , but who did actually ever process the
> request
> stored in the queue->backlog ? To me, it seems like the request was never
> processed, but we complete it.
Nobody. This is meant to indicate to t
On Mon, May 26, 2014 at 05:58:19PM +0200, Marek Vasut wrote:
> Hello,
>
> I'm digging in crypto/algapi.c , in the crypto_enqueue_request() function. I
> don't quite understand how the backlog mechanism should work. According to
> [1],
> I suspect it should limit the amount of requests in the qu
Hello again,
> Hello,
>
> I'm digging in crypto/algapi.c , in the crypto_enqueue_request() function.
> I don't quite understand how the backlog mechanism should work. According
> to [1], I suspect it should limit the amount of requests in the queue to
> $max_qlen and allow one more request to be
