On Wed, 2015-05-20 at 17:09 -0500, Suravee Suthikulpanit wrote:
> From http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf,
> section 6.2.17 _CCA states that ARM platforms require ACPI _CCA
> object to be specified for DMA-cabpable devices. Therefore, this patch
> specifies ACPI_CCA_REQU
On Fri, May 29, 2015 at 03:29:59AM +0200, Marek Vasut wrote:
> On Friday, May 29, 2015 at 03:23:59 AM, Herbert Xu wrote:
> > On Fri, May 29, 2015 at 03:00:35AM +0200, Marek Vasut wrote:
> > > My understanding (!) is that everyone should be able to use this key to
> > > encrypt/decrypt their data us
On Friday, May 29, 2015 at 03:23:59 AM, Herbert Xu wrote:
> On Fri, May 29, 2015 at 03:00:35AM +0200, Marek Vasut wrote:
> > My understanding (!) is that everyone should be able to use this key to
> > encrypt/decrypt their data using the AES128 engine in the DCP.
>
> If that's the case just make i
On Fri, May 29, 2015 at 03:00:35AM +0200, Marek Vasut wrote:
>
> My understanding (!) is that everyone should be able to use this key to
> encrypt/decrypt their data using the AES128 engine in the DCP.
If that's the case just make it the key you use if setkey has never
been called.
Cheers,
--
Em
On Friday, May 29, 2015 at 02:45:16 AM, Herbert Xu wrote:
> On Fri, May 29, 2015 at 02:40:54AM +0200, Marek Vasut wrote:
> > On Friday, May 29, 2015 at 02:37:00 AM, Herbert Xu wrote:
> > > On Thu, May 28, 2015 at 11:01:56AM -0500, Jay Monkman wrote:
> > > > Marek,
> > > >
> > > > I have a question
On Fri, May 29, 2015 at 02:40:54AM +0200, Marek Vasut wrote:
> On Friday, May 29, 2015 at 02:37:00 AM, Herbert Xu wrote:
> > On Thu, May 28, 2015 at 11:01:56AM -0500, Jay Monkman wrote:
> > > Marek,
> > >
> > > I have a question about the proper way to implement a feature. The
> > > DCP has the ab
On Friday, May 29, 2015 at 02:37:00 AM, Herbert Xu wrote:
> On Thu, May 28, 2015 at 11:01:56AM -0500, Jay Monkman wrote:
> > Marek,
> >
> > I have a question about the proper way to implement a feature. The
> > DCP has the ability to read a key for encryption/decryption from on
> > chip fuses. The
On Thu, May 28, 2015 at 02:23:33PM -0700, Tim Chen wrote:
>
> Quick question. When src and dst are different, the above code
> leave space for the assoc data in dst. However, I don't think we copy
> over the assoc data from src to dst.
> I assume we don't have to do that, right? If so, we have
On Thu, 2015-05-28 at 22:04 +0800, Herbert Xu wrote:
> @@ -1011,55 +966,55 @@ static int __driver_rfc4106_encrypt(struct
> aead_request *req)
> *(iv+4+i) = req->iv[i];
> *((__be32 *)(iv+12)) = counter;
>
> - if ((sg_is_last(req->src)) && (sg_is_last(req->assoc))) {
> +
Change the nx-842 common driver to wait for loading of both platform
drivers, and fail loading if the platform driver pointer is not set.
Add an independent platform driver pointer, that the platform drivers
set if they find they are able to load (i.e. if they find their platform
devicetree node(s)
On 05/28/2015 01:40 AM, Steffen Klassert wrote:
On Thu, May 28, 2015 at 12:18:51AM -0700, Alexander Duyck wrote:
On 05/27/2015 10:36 PM, Steffen Klassert wrote:
On Wed, May 27, 2015 at 10:40:32AM -0700, Alexander Duyck wrote:
This change makes it so that we use icmpv6_send to report PMTU issue
On Thursday, May 28, 2015 at 06:01:56 PM, Jay Monkman wrote:
> Marek,
Hi,
note that this discussion should really happen on the linux-crypto ML.
Moving the discussion to ML.
> I have a question about the proper way to implement a feature. The DCP
> has the ability to read a key for encryption/de
On 05/27/2015 07:36 PM, Herbert Xu wrote:
On Wed, May 27, 2015 at 09:12:02AM -0500, Tom Lendacky wrote:
The reason I'm asking is because while this patch fixes your driver
everybody else will still crash and burn should something like this
happen again.
A number of other drivers already have
On 05/27/2015 09:08 PM, Herbert Xu wrote:
> Do you have a specific piece of hardware in mind? What are its
> capabilities?
I'm going to use it with Intel's DH985xcc accelerator. It can accelerate
RSA, DH, ECDSA and ECDH just to name the most commonly used.
But I don't want to add anything that is
This patch adds setkey and setauthsize for cryptd AEAD.
Signed-off-by: Herbert Xu
---
crypto/cryptd.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/crypto/cryptd.c b/crypto/cryptd.c
index 4264c8d..74c4dcb 100644
--- a/crypto/cryptd.c
+++ b/crypto/
No new code should be using the return value of crypto_unregister_alg
as it will become void soon.
Signed-off-by: Herbert Xu
---
crypto/aead.c |4 ++--
include/crypto/internal/aead.h |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/crypto/aead.c b/c
This patch converts pcrypt over to the new AEAD interface.
Signed-off-by: Herbert Xu
---
crypto/pcrypt.c | 135
1 file changed, 40 insertions(+), 95 deletions(-)
diff --git a/crypto/pcrypt.c b/crypto/pcrypt.c
index ff174b6..45e7d51 1006
This patch converts cryptd to the new AEAD interface.
Signed-off-by: Herbert Xu
---
crypto/cryptd.c | 64 +---
1 file changed, 29 insertions(+), 35 deletions(-)
diff --git a/crypto/cryptd.c b/crypto/cryptd.c
index 74c4dcb..22ba81f 100644
--
This patch converts the low-level __gcm-aes-aesni algorithm to
the new AEAD interface.
Signed-off-by: Herbert Xu
---
arch/x86/crypto/aesni-intel_glue.c | 246 +++--
1 file changed, 79 insertions(+), 167 deletions(-)
diff --git a/arch/x86/crypto/aesni-intel_glue
This patch adds the helpers that allow the registration and removal
of multiple algorithms.
Signed-off-by: Herbert Xu
---
crypto/aead.c | 29 +
include/crypto/internal/aead.h |2 ++
2 files changed, 31 insertions(+)
diff --git a/crypto/aead.c
As it stands the only non-type safe functions left in the new
AEAD interface are the cra_init/cra_exit functions. It means
exposing the ugly __crypto_aead_cast to every AEAD implementor.
This patch adds type-safe init/exit functions to AEAD. Existing
algorithms are unaffected while new implement
This patch converts rfc4106-gcm-aesni to the new AEAD interface.
The low-level interface remains as is for now because we can't
touch it until cryptd itself is upgraded.
In the conversion I've also removed the duplicate copy of the
context in the top-level algorithm. Now all processing is carried
Now that type-safe init/exit functions exist, they often need
to access the underlying aead_instance. So this patch adds the
helper aead_alg_instance to access aead_instance from a crypto_aead
object.
Signed-off-by: Herbert Xu
---
include/crypto/internal/aead.h |5 +
1 file changed, 5
This patch ensures that the tfm context always has enough extra
memory to ensure that it is aligned according to cra_alignment.
Signed-off-by: Herbert Xu
---
crypto/algapi.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/crypto/algapi.c b/crypto/algapi.c
index abf100c.
Hi:
This series of patches adds some finishing touches to the new
AEAD interface and then converts pcrypt, cryptd and aesni_intel
to it.
Sorry for the resend but I screwed up the mailing list address.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://
On Thu, May 28, 2015 at 12:18:51AM -0700, Alexander Duyck wrote:
> On 05/27/2015 10:36 PM, Steffen Klassert wrote:
> >On Wed, May 27, 2015 at 10:40:32AM -0700, Alexander Duyck wrote:
> >>This change makes it so that we use icmpv6_send to report PMTU issues back
> >>into tunnels in the case that the
On 26 May 2015 at 15:26, Peter Ujfalusi wrote:
> Switch to use ma_request_slave_channel_compat_reason() to request the DMA
> channels. Only fall back to pio mode if the error code returned is not
> -EPROBE_DEFER, otherwise return from the probe with the -EPROBE_DEFER.
>
> Signed-off-by: Peter Ujfa
On 26 May 2015 at 15:26, Peter Ujfalusi wrote:
> Switch to use ma_request_slave_channel_compat_reason() to request the DMA
I guess it should be dma_request_slave_... huh, that was a long name. :-)
> channels. In case of error, return the error code we received including
> -EPROBE_DEFER
>
> Signe
On 26 May 2015 at 15:25, Peter Ujfalusi wrote:
> The driver will not probe without valid DMA channels so no need to check
> if they are valid when the module is removed.
>
> Signed-off-by: Peter Ujfalusi
> CC: Ulf Hansson
Acked-by: Ulf Hansson
Kind regards
Uffe
> ---
> drivers/mmc/host/omap
On 05/27/2015 10:36 PM, Steffen Klassert wrote:
On Wed, May 27, 2015 at 10:40:32AM -0700, Alexander Duyck wrote:
This change makes it so that we use icmpv6_send to report PMTU issues back
into tunnels in the case that the resulting packet is larger than the MTU
of the outgoing interface. Previo
30 matches
Mail list logo
