This patch defines the behaviour of AD in the new interface more
clearly. In particular, it specifies that if the user must copy
the AD to the destination manually when src != dst if they wish
to guarantee that the destination buffer contains a copy of the
AD.
The reason for this is that otherwis
This patch fixes a bug in the context size calculation where we
were still referring to the old cra_aead.
Signed-off-by: Herbert Xu
---
crypto/echainiv.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/echainiv.c b/crypto/echainiv.c
index 0f79fc6..62a817f 100644
--
This patch makes use of the new common IV generation code.
Signed-off-by: Herbert Xu
---
crypto/echainiv.c | 230 --
1 file changed, 18 insertions(+), 212 deletions(-)
diff --git a/crypto/echainiv.c b/crypto/echainiv.c
index 02d0543..0f79fc6
On module unload we weren't unregistering the seqniv template,
thus leading to a crash the next time someone walks the template
list.
Signed-off-by: Herbert Xu
---
crypto/seqiv.c |1 +
1 file changed, 1 insertion(+)
diff --git a/crypto/seqiv.c b/crypto/seqiv.c
index c0dba8f..2333974 100644
This patch adds some common IV generation code currently duplicated
by seqiv and echainiv. For example, the setkey and setauthsize
functions are completely identical.
Signed-off-by: Herbert Xu
---
crypto/aead.c | 205 +++-
include/crypto/i
As the AD does not necessarily exist in the destination buffer
it must be copied along with the plain text.
Signed-off-by: Herbert Xu
---
crypto/echainiv.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/crypto/echainiv.c b/crypto/echainiv.c
index bd85dcc..02d05
As the AD does not necessarily exist in the destination buffer
it must be copied along with the plain/cipher text.
Signed-off-by: Herbert Xu
---
crypto/seqiv.c | 33 ++---
1 file changed, 6 insertions(+), 27 deletions(-)
diff --git a/crypto/seqiv.c b/crypto/seqiv.
This patch makes use of the new common IV generation code.
Signed-off-by: Herbert Xu
---
crypto/seqiv.c | 92 ++---
1 file changed, 36 insertions(+), 56 deletions(-)
diff --git a/crypto/seqiv.c b/crypto/seqiv.c
index b55c685..9c4490b 100644
This patch fixes a bug in the context size calculation where we
were still referring to the old cra_aead.
Signed-off-by: Herbert Xu
---
crypto/seqiv.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/seqiv.c b/crypto/seqiv.c
index 9c4490b..c0dba8f 100644
--- a/crypt
We need to call sg_init_table as otherwise the first entry may
inadvertently become the last.
Signed-off-by: Herbert Xu
---
crypto/scatterwalk.c |1 +
1 file changed, 1 insertion(+)
diff --git a/crypto/scatterwalk.c b/crypto/scatterwalk.c
index 8690324..2ef9cbb 100644
--- a/crypto/scatterw
This patch tries to preserve in-place processing in old_crypt as
various algorithms are optimised for in-place processing where
src == dst.
Signed-off-by: Herbert Xu
---
crypto/aead.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/crypto/aead.c b/crypto/aead.c
index 7c
Hi:
Previously the AD was required to exist in both the source and
destination buffers. This creates a rather confusing situation
where the destination served as both input as well as output.
This series rectifies by allowing the destination to contain
the AD (e.g., it always does for in-place e
This change makes it so that if a tunnel is defined we just use the mark
from the tunnel instead of the mark from the skb header. By doing this we
can avoid the need to set skb->mark inside of the tunnel receive functions.
Signed-off-by: Alexander Duyck
---
net/xfrm/xfrm_input.c | 17
These patches are meant to try and address the fact the VTI tunnels are
currently overwriting the skb->mark value. I am generally happy with the
first two patches, however the third patch still modifies the skb->mark,
though it undoes after the fact.
The main problem I am trying to address is the
The vti6_rcv_cb and vti_rcv_cb calls were leaving the skb->mark modified
after completing the function. This resulted in the original skb->mark
value being lost. Since we only need skb->mark to be set for
xfrm_policy_check we can pull the assignment into the rcv_cb calls and then
just restore the
Instead of modifying skb->mark we can simply modify the flowi_mark that is
generated as a result of the xfrm_decode_session. By doing this we don't
need to actually touch the skb->mark and it can be preserved as it passes
out through the tunnel.
Signed-off-by: Alexander Duyck
---
net/ipv4/ip_vt
Scatter gather lists can be created with more available entries than are
actually used (e.g. using sg_init_table() to reserve a specific number
of sg entries, but in actuality using something less than that based on
the data length). The caller sometimes fails to mark the last entry
with sg_mark_e
Remove the length field from the ccp_sg_workarea since it is unused.
Signed-off-by: Tom Lendacky
---
drivers/crypto/ccp/ccp-ops.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/crypto/ccp/ccp-ops.c b/drivers/crypto/ccp/ccp-ops.c
index 71f2e3c..542453c 100644
--- a/drivers/crypto
The underlying device support will set the device dma_mask pointer
if DMA is set up properly for the device. Remove the check for and
assignment of dma_mask when it is null. Instead, just error out if
the dma_set_mask_and_coherent function fails because dma_mask is null.
Signed-off-by: Tom Lendac
The following patches are included in this driver update series:
- Remove the checking and setting of the device dma_mask field
- Remove an unused field from a structure to help avoid any confusion
- Protect against poorly marked end of scatter-gather list
This patch series is based on cryptodev
[ adding Boaz as this discussion has implications for ore_raid ]
On Tue, May 26, 2015 at 2:45 AM, Maxime Ripard
wrote:
> On Mon, May 18, 2015 at 10:06:55AM -0700, Dan Williams wrote:
>> On Mon, May 18, 2015 at 2:14 AM, Maxime Ripard
>> wrote:
>> > Hi Dan,
>> >
>> > On Wed, May 13, 2015 at 09:00:
On Tue, May 26, 2015 at 04:26:06PM +0300, 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.
I've got tw
* Peter Ujfalusi [150526 06:28]:
> Switch to use ma_request_slave_channel_compat_reason() to request the DMA
> channels. In case of error, return the error code we received including
> -EPROBE_DEFER
>
> Signed-off-by: Peter Ujfalusi
> CC: Greg Kroah-Hartman
> ---
> drivers/tty/serial/8250/8250
On Tue, May 26, 2015 at 04:25:58PM +0300, Peter Ujfalusi wrote:
> Switch to use ma_request_slave_channel_compat_reason() to request the DMA
> channels. In case of error, return the error code we received including
> -EPROBE_DEFER
I think you typed the function name wrong here :(
--
To unsubscribe
Hello Herbert Xu,
The patch a10f554fa7e0: "crypto: echainiv - Add encrypted chain IV
generator" from May 21, 2015, leads to the following static checker
warning:
crypto/echainiv.c:492 echainiv_alloc()
warn: 'inst' isn't an ERR_PTR
crypto/echainiv.c
435 static struct crypto_in
Am Dienstag, 26. Mai 2015, 15:57:59 schrieb Herbert Xu:
Hi Herbert,
>On Tue, May 26, 2015 at 09:56:17AM +0200, Stephan Mueller wrote:
>> Actually, I mean the real in-kernel crypto API: the IKE daemon would set up
>> the SA via XFRM where the rfc4106(gcm(aes)) cipher is set, is it not? So,
>> user
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 Ujfalusi
CC: Herbert Xu
CC: David S. Miller
CC: Lokesh Vut
of_dma_request_slave_channel should return either pointer for valid
dma_chan or ERR_PTR() error code, NULL is not expected to be returned.
Signed-off-by: Peter Ujfalusi
CC: Grant Likely
CC: Rob Herring
---
include/linux/of_dma.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Switch to use ma_request_slave_channel_compat_reason() to request the DMA
channels. In case of error, return the error code we received including
-EPROBE_DEFER
Signed-off-by: Peter Ujfalusi
CC: Ulf Hansson
---
drivers/mmc/host/omap_hsmmc.c | 22 ++
1 file changed, 10 inserti
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
---
drivers/mmc/host/omap_hsmmc.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/omap_
dma_request_slave_channel_compat() 'eats' up the returned error codes which
prevents drivers using the compat call to be able to do deferred probing.
The new wrapper is identical in functionality but it will return with error
code in case of failure and will pass the -EPROBE_DEFER to the caller in
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 Ujfalusi
CC: Ulf Hansson
---
drivers/mmc/host/davinci_mmc.
Switch to use ma_request_slave_channel_compat_reason() to request the DMA
channel. 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 Ujfalusi
CC: Laurent Pinchart
CC: Mauro Carvalho Chehab
---
Switch to use ma_request_slave_channel_compat_reason() to request the DMA
channel. Only fall back to polling mode if the error code returned is not
-EPROBE_DEFER, otherwise return from the probe with the -EPROBE_DEFER.
Signed-off-by: Peter Ujfalusi
CC: Herbert Xu
CC: David S. Miller
CC: Lokesh
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 Ujfalusi
CC: Herbert Xu
CC: David S. Miller
CC: Lokesh Vut
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 Ujfalusi
CC: Mark Brown
---
drivers/spi/spi-omap2-mcspi.c
dmaengine provides a wrapper function to handle DT and non DT boots when
requesting DMA channel. Use that instead of checking for of_node in the
platform driver.
Signed-off-by: Peter Ujfalusi
CC: Mark Brown
CC: Jarkko Nikula
CC: Liam Girdwood
---
sound/soc/omap/omap-pcm.c | 16 ++-
Hi,
Vinod: as I promised: https://lkml.org/lkml/2015/5/8/80
With this series it is possible to put omap-dma or edma to even late_initcall
and the drivers will figure out the load order fine(ish).
We need to add dma_request_slave_channel_compat_reason() which is the equivalent
of dma_request_slave
Switch to use ma_request_slave_channel_compat_reason() to request the DMA
channels. In case of error, return the error code we received including
-EPROBE_DEFER
Signed-off-by: Peter Ujfalusi
CC: Greg Kroah-Hartman
---
drivers/tty/serial/8250/8250_dma.c | 18 --
1 file changed, 8
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 Ujfalusi
CC: Ulf Hansson
CC: Jarkko Nikula
---
drivers/mm
Hi Paul,
this patch is also for omap2... Can you review it too?
On Saturday 28 February 2015 17:24:36 Pavel Machek wrote:
> On Thu 2015-02-26 14:49:52, Pali Rohár wrote:
> > Register crypto hwmod links only if they are not disabled in DT.
> > If DT information is missing, enable them only for GP
On Tue, May 26, 2015 at 11:22:45AM +0200, Imre Kaloz wrote:
> On Tue, 26 May 2015 10:59:36 +0200, Boris Brezillon
> wrote:
>
>
>
> >>As the crypto engine really depend on the SoC itself and not of
> >>the board,
> >>what about updating the dts of the other board using an Armada XP?
> >
> >But t
On Mon, May 18, 2015 at 10:06:55AM -0700, Dan Williams wrote:
> On Mon, May 18, 2015 at 2:14 AM, Maxime Ripard
> wrote:
> > Hi Dan,
> >
> > On Wed, May 13, 2015 at 09:00:46AM -0700, Dan Williams wrote:
> >> On Wed, May 13, 2015 at 2:17 AM, Maxime Ripard
> >> wrote:
> >> > Hi Dan,
> >> >
> >> > On
On Tue, May 26, 2015 at 11:10:51AM +0200, Boris Brezillon wrote:
> On Tue, 26 May 2015 09:06:29 +
> Jason Cooper wrote:
>
> > On Mon, May 25, 2015 at 08:43:02PM +0200, Boris Brezillon wrote:
> > > Jason, Gregory,
> > >
> > > On Mon, 25 May 2015 16:46:51 +
> > > Jason Cooper wrote:
> > >
On Tue, 26 May 2015 10:59:36 +0200, Boris Brezillon
wrote:
As the crypto engine really depend on the SoC itself and not of the
board,
what about updating the dts of the other board using an Armada XP?
But that means introducing changes I haven't tested. Are you okay with
that ?
Well,
Hi Gregory,
On Mon, 25 May 2015 17:33:24 +0200
Gregory CLEMENT wrote:
> Hi Boris, Arnaud,
>
>
>
> On 22/05/2015 15:34, Boris Brezillon wrote:
> > From: Arnaud Ebalard
> >
> > Add crypto related nodes in armada-370.dtsi.
> >
> > Signed-off-by: Arnaud Ebalard
> > Signed-off-by: Boris Brezil
On Tue, 26 May 2015 11:10:41 +0200
Thomas Petazzoni wrote:
> Dear Boris Brezillon,
>
> On Tue, 26 May 2015 11:03:45 +0200, Boris Brezillon wrote:
>
> > > There is no clocks property. After a quick look on the datasheet, indeed
> > > I didn't
> > > find any clock which match the CESA. In this c
On Mon, May 25, 2015 at 08:43:02PM +0200, Boris Brezillon wrote:
> Jason, Gregory,
>
> On Mon, 25 May 2015 16:46:51 +
> Jason Cooper wrote:
>
> > On Mon, May 25, 2015 at 05:39:13PM +0200, Gregory CLEMENT wrote:
> > > Hi Boris, Arnaud,
> > >
> > > On 22/05/2015 15:34, Boris Brezillon wrote:
On Tue, 26 May 2015 09:06:29 +
Jason Cooper wrote:
> On Mon, May 25, 2015 at 08:43:02PM +0200, Boris Brezillon wrote:
> > Jason, Gregory,
> >
> > On Mon, 25 May 2015 16:46:51 +
> > Jason Cooper wrote:
> >
> > > On Mon, May 25, 2015 at 05:39:13PM +0200, Gregory CLEMENT wrote:
> > > > Hi
On Mon, 25 May 2015 17:10:37 +0200
Gregory CLEMENT wrote:
> Hi Boris,
>
> On 22/05/2015 15:34, Boris Brezillon wrote:
> > Enable the crypto IP on armada-xp-gp.
> >
> > Signed-off-by: Boris Brezillon
> > ---
> > arch/arm/boot/dts/armada-xp-gp.dts | 4 +++-
> > 1 file changed, 3 insertions(+),
Dear Boris Brezillon,
On Tue, 26 May 2015 11:03:45 +0200, Boris Brezillon wrote:
> > There is no clocks property. After a quick look on the datasheet, indeed I
> > didn't
> > find any clock which match the CESA. In this case you should update the
> > binding
> > documentation by adding that the
Hi Linus:
This push disables the newly (4.1) added user-space AEAD interface
so that we can fix issues in the underlying kernel AEAD interface.
Once the new kernel AEAD interface is ready we can then reenable
the user-space AEAD interface.
Please pull from
git://git.kernel.org/pub/scm/linux/ker
Am Dienstag, 26. Mai 2015, 16:18:01 schrieb Herbert Xu:
Hi Herbert,
>
>This is all in the patch series that you're responding. So please
>actually read it rather than making assumptions :)
Sorry, you are right -- I overlooked the xfrm_algo_desc change. Thanks for
helping.
Ciao
Stephan
--
To u
On Tue, May 26, 2015 at 10:15:37AM +0200, Stephan Mueller wrote:
>
> I fully understand that. But the current patch set that we discuss modifies
> the IPSEC implementation of esp_ouput to use the new interface. Therefore, to
> use rfc4106(gcm(aes)) *with* the IV generator (i.e. to get the old rem
Am Dienstag, 26. Mai 2015, 15:38:59 schrieb Herbert Xu:
Hi Herbert,
>On Tue, May 26, 2015 at 09:37:09AM +0200, Stephan Mueller wrote:
>> - the current IKE implementations use rfc4106(gcm(aes)). They would need to
>> use seqniv(rfc4106(gcm(aes))) depending on the kernel version. So, we have
>> a
>
On Tue, May 26, 2015 at 09:57:51AM +0200, Stephan Mueller wrote:
>
> Ok. Would you look into that one or shall I do that?
I'll reenable it immediately after the patch to convert it to
the new interface is merged.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP K
On Tue, May 26, 2015 at 09:56:17AM +0200, Stephan Mueller wrote:
>
> Actually, I mean the real in-kernel crypto API: the IKE daemon would set up
> the SA via XFRM where the rfc4106(gcm(aes)) cipher is set, is it not? So,
> user
> space is responsible to set the right IPSEC cipher.
>
> As that u
Am Dienstag, 26. Mai 2015, 15:36:05 schrieb Herbert Xu:
Hi Herbert,
>
>In order to allow this to be done I'm going to disable the AEAD
>user-space interface in 4.1 so that we have time to fix it properly
>for 4.2.
Ok. Would you look into that one or shall I do that?
Ciao
Stephan
--
To unsubscrib
On Tue, May 26, 2015 at 03:38:58PM +0800, Herbert Xu wrote:
> On Tue, May 26, 2015 at 09:37:09AM +0200, Stephan Mueller wrote:
> >
> > - the current IKE implementations use rfc4106(gcm(aes)). They would need to
> > use seqniv(rfc4106(gcm(aes))) depending on the kernel version. So, we have
> > a
On Tue, May 26, 2015 at 09:37:09AM +0200, Stephan Mueller wrote:
>
> - the current IKE implementations use rfc4106(gcm(aes)). They would need to
> use seqniv(rfc4106(gcm(aes))) depending on the kernel version. So, we have a
> clear change in the user space API where the old configuration even wor
On Tue, May 26, 2015 at 08:44:29AM +0200, Stephan Mueller wrote:
>
> Confirmed. I see no more issues on the AF_ALG side.
OK it works but there is a more serious issue. In particular, the
user-space interface only provides spaces for the AD in the source
and not in the destination.
That means if
Am Dienstag, 26. Mai 2015, 15:21:52 schrieb Herbert Xu:
Hi Herbert,
>On Tue, May 26, 2015 at 08:39:56AM +0200, Stephan Mueller wrote:
>> May I also ask where I can find the generated IV when using
>> rfc4106(gcm(aes))?
>You need to use the IV generator, seqniv(rfc4106(gcm(aes)))
Thank you, that
The newly added AEAD user-space isn't quite ready for prime time
just yet. In particular it is conflicting with the AEAD single
SG list interface change so this patch disables it now.
Once the SG list stuff is completely done we can then renable
this interface.
Signed-off-by: Herbert Xu
diff -
On Tue, May 26, 2015 at 08:39:56AM +0200, Stephan Mueller wrote:
>
> May I also ask where I can find the generated IV when using
> rfc4106(gcm(aes))?
You need to use the IV generator, seqniv(rfc4106(gcm(aes)))
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP K
Am Dienstag, 26. Mai 2015, 08:39:56 schrieb Stephan Mueller:
Hi,
>Am Freitag, 22. Mai 2015, 15:19:23 schrieb Herbert Xu:
>
>Hi Herbert,
>
>> On Fri, May 22, 2015 at 09:16:08AM +0200, Stephan Mueller wrote:
>> > Thanks for the pointer, but there I do not really see the functionality I
>> > am look
65 matches
Mail list logo
