On Thu, Nov 20, 2014 at 08:11:42AM +0100, Steffen Klassert wrote:
>
> I think this is not sufficient, crypto_alg_match() will now return the first
> algorithm in crypto_alg_list that matches cra_name. We would need to extend
> crypto_alg_match() to return the algorithm with the highest priority in
On Thu, Nov 20, 2014 at 08:26:51AM +0100, Steffen Klassert wrote:
>
> What about to use a fallback algorithm that does not need to touch
> FPU/SIMD in such cases? We would not need cryptd at all and it would
> keep the requests in the right order because we don't defer them.
This would be bad for
On Sat, Nov 15, 2014 at 11:15:50AM +0800, Herbert Xu wrote:
> On Wed, Nov 12, 2014 at 09:41:38AM +0100, Steffen Klassert wrote:
> >
> > Everything below the local_bh_enable() should not run in atomic context
> > as the subsequent functions may set the CRYPTO_TFM_REQ_MAY_SLEEP flag.
>
> Actually I'
On Thu, Nov 20, 2014 at 12:46:50PM +0800, Herbert Xu wrote:
> On Thu, Nov 20, 2014 at 05:23:23AM +0100, Stephan Mueller wrote:
> >
> > Here is the code:
> >
> > static int crypto_report(struct sk_buff *in_skb, struct nlmsghdr *in_nlh,
> > struct nlattr **attrs)
> > {
> > ...
On Thu, Nov 20, 2014 at 05:03:24AM +0100, Stephan Mueller wrote:
> Am Dienstag, 18. November 2014, 22:08:23 schrieb Herbert Xu:
>
> Hi Herbert, Steffen,
>
> >
> > We already have crypto_user so you should be extending that to
> > cover what's missing.
>
> After playing a bit with the interface,
On Thu, Nov 20, 2014 at 05:03:24AM +0100, Stephan Mueller wrote:
>
> Btw: is there an example that uses that interface? The ordering of data
> structures in the netlink message is not really clear from looking at the
> code.
I wrote to tool that uses this API some time ago, it is still
a bit ru
On Thu, Nov 20, 2014 at 05:23:23AM +0100, Stephan Mueller wrote:
>
> Here is the code:
>
> static int crypto_report(struct sk_buff *in_skb, struct nlmsghdr *in_nlh,
>struct nlattr **attrs)
> {
> ...
> if (!p->cru_driver_name[0])
> return -EINVAL;
OK le
Am Donnerstag, 20. November 2014, 12:18:24 schrieb Herbert Xu:
Hi Herbert,
> On Thu, Nov 20, 2014 at 05:14:49AM +0100, Stephan Mueller wrote:
> > Or we have to patch crypto_user to allow the use of cra_name -- which is
> > currently explicitly disabled.
>
> In what way is it disabled?
Here is t
On Thu, Nov 20, 2014 at 05:14:49AM +0100, Stephan Mueller wrote:
>
> Or we have to patch crypto_user to allow the use of cra_name -- which is
> currently explicitly disabled.
In what way is it disabled?
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http
Am Donnerstag, 20. November 2014, 12:07:48 schrieb Herbert Xu:
Hi Herbert,
> On Thu, Nov 20, 2014 at 05:03:24AM +0100, Stephan Mueller wrote:
> > crypto_user cannot be applied to the currently active cipher that one has
> > open with AF_ALG. For getting information, one has to call crypto_user
>
On Thu, Nov 20, 2014 at 05:03:24AM +0100, Stephan Mueller wrote:
>
> crypto_user cannot be applied to the currently active cipher that one has
> open
> with AF_ALG. For getting information, one has to call crypto_user with the
> cra_driver_name of a cipher. (Why is that limitation, btw (see cryp
On Wed, Nov 19, 2014 at 05:15:47PM +0100, Nicolas Ferre wrote:
> On 19/11/2014 17:07, Boris Brezillon :
> > Hello,
> >
> > This series adds DT support for the TRNG (True Random Generator) block and
> > adds missing trng nodes to dtsi files.
>
> Nitpicking: subject of this cover letter seems not g
Am Dienstag, 18. November 2014, 22:08:23 schrieb Herbert Xu:
Hi Herbert, Steffen,
> On Sun, Nov 16, 2014 at 03:24:25AM +0100, Stephan Mueller wrote:
> > The AF_ALG interface allows normal cipher (hash, encrypt, decrypt).
> > However, it does not allow user space to obtain the following generic
>
From: Johannes Berg
This is a specific implementation, is the
multiplexer that has the arch-specific knowledge of which
of the implementations needs to be used, so include that.
Signed-off-by: Johannes Berg
---
drivers/crypto/bfin_crc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
d
Hi All,
Apologies for this approach, but although my email replies seem to get
through to the mailing list, my patches dont (although they do appear to
land on the device tree list).
I'm sure Herbert will have received it in his inbox, but for anyone else
who might want to comment on the pat
On Wed, 19 Nov 2014 18:35:56 +0100
Nicolas Ferre wrote:
> On 19/11/2014 17:18, Boris Brezillon :
> > On Wed, 19 Nov 2014 17:15:47 +0100
> > Nicolas Ferre wrote:
> >
> >> On 19/11/2014 17:07, Boris Brezillon :
> >>> Hello,
> >>>
> >>> This series adds DT support for the TRNG (True Random Generat
On 19/11/2014 17:18, Boris Brezillon :
> On Wed, 19 Nov 2014 17:15:47 +0100
> Nicolas Ferre wrote:
>
>> On 19/11/2014 17:07, Boris Brezillon :
>>> Hello,
>>>
>>> This series adds DT support for the TRNG (True Random Generator) block and
>>> adds missing trng nodes to dtsi files.
>>
>> Nitpicking:
This module registers a crc32 algorithm and a crc32c algorithm
that use the optional CRC32 and CRC32C instructions in ARMv8.
Tested on AMD Seattle.
Improvement compared to crc32c-generic algorithm:
TCRYPT CRC32C speed test shows ~450% speedup.
Simple dd write tests to btrfs filesystem show ~30% s
On Wed, 19 Nov 2014 17:15:47 +0100
Nicolas Ferre wrote:
> On 19/11/2014 17:07, Boris Brezillon :
> > Hello,
> >
> > This series adds DT support for the TRNG (True Random Generator) block and
> > adds missing trng nodes to dtsi files.
>
> Nitpicking: subject of this cover letter seems not good ;
On 19/11/2014 17:07, Boris Brezillon :
> Hello,
>
> This series adds DT support for the TRNG (True Random Generator) block and
> adds missing trng nodes to dtsi files.
Nitpicking: subject of this cover letter seems not good ;-)
Herbert, do you think you can take this series yourself or do I have
Document DT bindings of Atmel's TRNG (True Random Number Generator) IP.
Signed-off-by: Boris Brezillon
Acked-by: Nicolas Ferre
---
Documentation/devicetree/bindings/hwrng/atmel-trng.txt | 16
1 file changed, 16 insertions(+)
create mode 100644 Documentation/devicetree/bindings
Add a DT node for the TRNG (True Random Number Generator) block.
Keep this block enabled as it does not depend on any external connection,
and thus should be available on all boards.
Signed-off-by: Boris Brezillon
Acked-by: Nicolas Ferre
---
arch/arm/boot/dts/at91sam9g45.dtsi | 7 +++
1 fi
Commit e1bd95bf7c25 ("crypto: algif - zeroize IV buffer") and
2a6af25befd0 ("crypto: algif - zeroize message digest buffer")
added memzero_explicit() calls on buffers that are later on
passed back to sock_kfree_s().
This is a discussed follow-up that, instead, extends the sock
API and adds sock_kz
Hello,
This series adds DT support for the TRNG (True Random Generator) block and
adds missing trng nodes to dtsi files.
Best Regards,
Boris
Boris Brezillon (4):
hwrng: atmel: use clk_prepapre_enable/_disable_unprepare
hwrng: atmel: add DT support
hwrng: atmel: Add TRNG DT binding doc
Use clk_prepare_enable/_disable_unprepare instead of clk_enable/disable
to work properly with the CCF.
Signed-off-by: Boris Brezillon
Acked-by: Peter Korsgaard
Acked-by: Nicolas Ferre
---
drivers/char/hw_random/atmel-rng.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --g
Add DT support.
Make the driver depend on CONFIG_OF as at91sam9g45 was the only SoC making
use of the TRNG block and this SoC is now fully migrated to DT.
Signed-off-by: Boris Brezillon
Acked-by: Nicolas Ferre
---
drivers/char/hw_random/Kconfig | 2 +-
drivers/char/hw_random/atmel-rng.c |
On Wed, Nov 19, 2014 at 12:41 PM, Julia Lawall wrote:
>> +// Comments: There are false positives in crypto/ where they are
>> actually freed.
>
> I didn't really understand this comment. I ran the semantic patch and got
> around 10 results, but it wasn't clear to me how to see which were false
>
On Mon, Nov 17, 2014 at 06:52:40PM +, Terence Eden wrote:
> From: Terence Eden
>
> "its" == "something belong to it". "it's" == "it is", "it has", "it
> was", etc. Sorry - just bugged me as I was reading the code.
> (Resubmitting - hopefully correctly!)
>
> Signed-off-by: Terence Eden
> ---
> +// Comments: There are false positives in crypto/ where they are
> actually freed.
I didn't really understand this comment. I ran the semantic patch and got
around 10 results, but it wasn't clear to me how to see which were false
positives.
I would suggest to extend the rule a little bit to i
From: Markus Elfring
Date: Wed, 19 Nov 2014 10:11:04 +0100
The kzfree() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
crypto/drb
30 matches
Mail list logo
