On Mon, May 26, 2014 at 07:42:57AM +0200, Stephan Mueller wrote:
>
> A second aspect is the implementation of the stdrng. Currently, the offered
> patch does not include the stdrng selection. I am currently working on the
> completion of the addition of the stdrng selection to the offered patch.
On Thu, May 22, 2014 at 06:25:15PM +0200, Jean Delvare wrote:
> You can select MPILIB_EXTRA all you want, it doesn't exist ;-)
>
> Surprised kconfig doesn't complain about that...
>
> Signed-off-by: Jean Delvare
> Cc: Herbert Xu
> Cc: "David S. Miller"
This patch should go to David Howells
On Fri, May 23, 2014 at 04:02:12PM -0700, Tim Chen wrote:
>
> The outline of the algorithm is sketched below:
> Any driver requesting the crypto service will place an async
> crypto request on the workqueue. The multi-buffer crypto daemon will
> pull request from work queue and put each request in
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
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
Am Freitag, 30. Mai 2014, 17:05:48 schrieb Herbert Xu:
Hi Herbert,
> On Mon, May 26, 2014 at 07:42:57AM +0200, Stephan Mueller wrote:
> > A second aspect is the implementation of the stdrng. Currently, the
> > offered
> > patch does not include the stdrng selection. I am currently working on the
Hi Herbert,
On Fri, 30 May 2014 17:18:54 +0800, Herbert Xu wrote:
> On Thu, May 22, 2014 at 06:25:15PM +0200, Jean Delvare wrote:
> > You can select MPILIB_EXTRA all you want, it doesn't exist ;-)
> >
> > Surprised kconfig doesn't complain about that...
> >
> > Signed-off-by: Jean Delvare
> > C
On Fri, May 30, 2014 at 12:08:08PM +0200, Stephan Mueller wrote:
>> > We already have a user-space interface to change priorities.
>
> Great -- if I may ask, which interface is that?
Take a look at crypto/crypto_user.c
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert
Hi,
http://lwn.net/Articles/410848/
The following code is taken from the above page:
int main(void)
{
int opfd;
int tfmfd;
struct sockaddr_alg sa = {
.salg_family = AF_ALG,
.salg_type = "skcipher",
.salg_name = "cbc(aes)"
};
struct msghdr msg = {};
struct cmsghdr *cmsg;
char cbuf[CMSG_SPACE(4) +
Jean Delvare wrote:
> > This patch should go to David Howells
>
> Why? How could I find out?
Try "git log".
David
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/maj
You can select MPILIB_EXTRA all you want, it doesn't exist ;-)
Surprised kconfig doesn't complain about that...
Signed-off-by: Jean Delvare
Acked-by: Marek Vasut
Cc: David Howells
Cc: Herbert Xu
Cc: "David S. Miller"
---
Resent with David Howells added to Cc.
crypto/asymmetric_keys/Kconfig
Herbert:
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
backlogging function, does it break anything? How critical is it
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
>
Hi! Herbert:
In a system of multi cpu core, with multiple crypto hardware, different irq
for each, is it possible the udp receive get out of order for the same tfm?
Let us say, of the same tfm, driver distributes requests to any available
crypto hardware. For the same tfm, driver re-sequenc
On Fri, 2014-05-30 at 17:26 +0800, Herbert Xu wrote:
> On Fri, May 23, 2014 at 04:02:12PM -0700, Tim Chen wrote:
> >
> > The outline of the algorithm is sketched below:
> > Any driver requesting the crypto service will place an async
> > crypto request on the workqueue. The multi-buffer crypto dae
15 matches
Mail list logo
