> Von: Kim Phillips [kim.phill...@freescale.com]
> Gesendet: Samstag, 7. März 2015 01:46
> An: Herbert Xu; Benjamin Herrenschmidt; Paul Mackerras; Michael Ellerman
> Cc: Markus Stockhausen; linux-cry...@vger.kernel.org;
> linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org
> Betreff: [PATC
On Fri, 2015-03-06 at 15:50 -0800, Olof Johansson wrote:
> On Fri, Mar 6, 2015 at 2:56 PM, Benjamin Herrenschmidt
> wrote:
> > On Fri, 2015-03-06 at 10:00 -0500, Steven Rostedt wrote:
> >> On Fri, 06 Mar 2015 15:18:42 +1100
> >> Benjamin Herrenschmidt wrote:
> >>
> >>
> >> > Can you shoot me the
On Mar 6, 2015, at 3:07 PM, linuxppc-dev-requ...@lists.ozlabs.org wrote:
> Date: Sat, 07 Mar 2015 09:56:22 +1100
> From: Benjamin Herrenschmidt
> To: Steven Rostedt
> Cc: Grant Likely , Rob Herring
> , Olof Johansson ,
> linuxppc-dev@lists.ozlabs.org, LKML
> Subject: Re: [REGRESSION
On Fri, 6 Mar 2015 11:49:43 -0500
Martin Hicks wrote:
> On Thu, Mar 5, 2015 at 7:16 PM, Kim Phillips
> wrote:
> > On Fri, 20 Feb 2015 12:00:10 -0500
> > Martin Hicks wrote:
> >
> >> The newer talitos hardware has support for AES in XTS mode.
> >
> > Assuming it's the same thing, AES-XCBC gets
On Wed, 2015-03-04 at 23:45 -0600, Emil Medve wrote:
> From: Igal Liberman
>
> Signed-off-by: Igal Liberman
> ---
> drivers/soc/Kconfig |1 +
> drivers/soc/Makefile |1 +
> drivers/soc/fsl/Kconfig |1 +
> drivers/soc/fsl/Makefile |1 +
> drivers/soc
The current cryptodev-2.6 tree commits:
d9850fc529ef ("crypto: powerpc/sha1 - kernel config")
50ba29aaa7b0 ("crypto: powerpc/sha1 - glue")
failed to properly place files under arch/powerpc/crypto, which
leads to build errors:
make[1]: *** No rule to make target 'arch/powerpc/crypto/sha1-spe-asm.
On Fri, Mar 6, 2015 at 2:56 PM, Benjamin Herrenschmidt
wrote:
> On Fri, 2015-03-06 at 10:00 -0500, Steven Rostedt wrote:
>> On Fri, 06 Mar 2015 15:18:42 +1100
>> Benjamin Herrenschmidt wrote:
>>
>>
>> > Can you shoot me the DT (/proc/device-tree in a tarball) ?
>>
>> Attached.
>
> This is indeed
On Sat, 07 Mar 2015 09:56:22 +1100
Benjamin Herrenschmidt wrote:
> In the meantime, try that patch:
>
It boots for me.
Tested-by: Steven Rostedt
-- Steve
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo
On Fri, 2015-03-06 at 10:00 -0500, Steven Rostedt wrote:
> On Fri, 06 Mar 2015 15:18:42 +1100
> Benjamin Herrenschmidt wrote:
>
>
> > Can you shoot me the DT (/proc/device-tree in a tarball) ?
>
> Attached.
This is indeed a bug in their DT. We might want to add quirks for
that unless it can b
Hi Kim,
On Fri, Mar 6, 2015 at 11:49 AM, Martin Hicks wrote:
> On Thu, Mar 5, 2015 at 7:16 PM, Kim Phillips
> wrote:
>> On Fri, 20 Feb 2015 12:00:10 -0500
>> Martin Hicks wrote:
>>
>>> The newer talitos hardware has support for AES in XTS mode.
>>
>> Assuming it's the same thing, AES-XCBC gets
On Fri, Feb 20, 2015 at 04:53:08PM +1100, Gavin Shan wrote:
> On Thu, Feb 19, 2015 at 04:57:47PM -0200, casca...@linux.vnet.ibm.com wrote:
> >On Tue, Feb 17, 2015 at 09:36:47AM +1100, Gavin Shan wrote:
> >> On Mon, Feb 16, 2015 at 11:14:27AM -0200, casca...@linux.vnet.ibm.com
> >> wrote:
> >> >On
On Thu, Mar 5, 2015 at 7:16 PM, Kim Phillips wrote:
> On Fri, 20 Feb 2015 12:00:10 -0500
> Martin Hicks wrote:
>
>> The newer talitos hardware has support for AES in XTS mode.
>
> Assuming it's the same thing, AES-XCBC gets added with SEC v3.0
> h/w. Assuming hw_supports() doesn't already suppor
The purpose of this set of patchs is to add to talitos crypto driver the
support for the SEC1 version of the security engine, which is found in
mpc885 and mpc8272 processors.
The approach has been to split the driver in two main parts:
* talitos.c and talitos.h contains parts that are common
* tal
This patch updates the documentation by including SEC1 into SEC2/3 doc
Signed-off-by: Christophe Leroy
---
Documentation/devicetree/bindings/crypto/fsl-sec2.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec2.txt
b/Docu
SEC1 bugs on 0 data hash, so we submit an already padded block representing 0
data
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 3 +++
drivers/crypto/talitos1.c | 21 +
drivers/crypto/talitos1.h | 4
drivers/crypto/talitos2.h | 6 ++
4 files c
This patch adds talitos1.c and talitos1.h with all specificities needed
to handle the SEC1 security engine found in MPC885 and MPC8272.
The SEC1 has several differences with its younger brother SEC2:
* Several bits in registers have different locations
* Many bits are missing
* Some bits are in ad
j_extent field is specific to SEC2 so we add a helper function to clear it
so that SEC1 can redefine that function as nop
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 2 +-
drivers/crypto/talitos2.h | 5 +
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/driv
move sg_count() helper into talitos.h as it will be needed by SEC1 specific
functions
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 20
drivers/crypto/talitos.h | 21 +
2 files changed, 21 insertions(+), 20 deletions(-)
diff --git a/dr
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 4 +---
drivers/crypto/talitos2.h | 2 ++
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 8b627d0..0262e75 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/
Move hash chain handling into talitos2.h as only SEC2 has sg chaining
capatibility
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 34 --
drivers/crypto/talitos2.h | 34 ++
2 files changed, 34 insertions(+), 34 del
Move reset/init helpers init talitos2.h as they are specific to SEC2
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 19 ---
drivers/crypto/talitos2.h | 20
2 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/drivers/crypto/talit
Move interrupt related macros in talitos2.h as they are specific to SEC2
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 58 -
drivers/crypto/talitos2.h | 60 +++
2 files changed, 60 insertio
SEC2 and SEC1 error handling will be different because so many bits are
different. So we move error handling into talitos2.c
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 103 +-
drivers/crypto/talitos.h | 8
drivers/crypto/t
In order to be able to manage differences between SEC1 and SEC2, we split
talitos.h into two parts.
talitos2.h will contain all parts that are specific to SEC2 and different on
SEC1
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.h | 163 +---
driver
SEC1 doesn't have IPSec descriptor, so all functions using that descriptor
are specific to SEC2. This patch moves them in a new talitos2.c file
dedicated to SEC2
We also move to talitos2.c all the functions that will be different for
SEC1, like the handling of mapping/unmapping of input/output sca
SEC1 doesn't support scatter/gather, therefore this part of the code will
have to be implemented differently for SEC1, so we isolate it in a small
helper function
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 29 +++--
1 file changed, 19 insertions(+), 1
During init and reset, some actions are different between SEC1 and SEC2
This patch isolates them in small helper functions that we will be able
to redefine for SEC1
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 20
1 file changed, 16 insertions(+), 4 deleti
This patch refactors the handling of the input and output data that is quite
similar in several functions
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 163 ---
1 file changed, 85 insertions(+), 78 deletions(-)
diff --git a/drivers/c
Do use zero_entry value to init the descriptors ptrs to zero instead of
writing 0 in each field
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 103b
SEC1 and SEC2 have different EU base addresses, so define base addresses
as #define
SEC1 and SEC2 have different bit masks for ISR registers, so create a
macro to define them
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.h | 85 ++--
1 fi
On Mar 4, 2015, at 11:45 PM, Emil Medve wrote:
> From: Igal Liberman
>
> The Freescale Data Path Acceleration Architecture (DPAA) is a set of
> hardware components on specific QorIQ P and T series multicore processors.
> This architecture provides the infrastructure to support simplified
> sha
Hi Emil,
On 03/05/15 10:04, Emil Medve wrote:
Hello Jamal,
On 03/05/2015 08:35 AM, Jamal Hadi Salim wrote:
Hi Emil,
No. All the kernel drivers/code we want to upstream is meant to stand on
its own and be used the "normal" Linux/Unix way
Ok, thanks - that was my only concern.
Note there
On Fri, 06 Mar 2015 15:18:42 +1100
Benjamin Herrenschmidt wrote:
> Can you shoot me the DT (/proc/device-tree in a tarball) ?
Attached.
-- Steve
device-tree.tar.bz2
Description: application/bzip
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.oz
On 03/06/2015 10:57 AM, Nishanth Aravamudan wrote:
On 05.03.2015 [15:29:00 -0800], David Rientjes wrote:
On Thu, 5 Mar 2015, Nishanth Aravamudan wrote:
So if we compare to x86:
arch/x86/mm/numa.c::numa_init():
nodes_clear(numa_nodes_parsed);
nodes_clear(node_possible_map);
On Fri, Mar 6, 2015 at 3:33 AM, Yijing Wang wrote:
> Now we could use pci_scan_host_bridge() to scan
> pci buses, provide powerpc specific pci_host_bridge_ops.
>
> Suggested-by: Arnd Bergmann
> Signed-off-by: Yijing Wang
> CC: Benjamin Herrenschmidt
> CC: linuxppc-dev@lists.ozlabs.org
> Signed-
Kim Phillips wrote:
> On Tue, 3 Mar 2015 08:21:34 -0500
> Martin Hicks wrote:
>
>> This is properly defined in the md5 header file.
>>
>> Signed-off-by: Martin Hicks
>> ---
>
> Acked-by: Kim Phillips
Patches 1-2 applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au
On Wed, Mar 04, 2015 at 09:00:39AM +0100, leroy christophe wrote:
> Le 03/03/2015 19:44, Mark Brown a écrit :
> >Why are we using of_iomap() rather than a generic I/O mapping function
> >here?
> because all drivers for powerpc seems to be using of_iomap(), as on powerpc
> the HW is described by t
Now we could pass PCI domain combined with bus number
in u32 argu. Because in arm/arm64, PCI domain number
is assigned by pci_bus_assign_domain_nr(). So we leave
pci_scan_root_bus() and pci_create_root_bus() in arm/arm64
unchanged. A new function pci_host_assign_domain_nr()
will be introduced for a
Now we could use pci_scan_host_bridge() to scan
pci buses, provide powerpc specific pci_host_bridge_ops.
Suggested-by: Arnd Bergmann
Signed-off-by: Yijing Wang
CC: Benjamin Herrenschmidt
CC: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Bjorn Helgaas
---
arch/powerpc/include/asm/machdep.h
Pcibios_root_bridge_prepare() in powerpc is used
to set root bus speed. Rename it to
pcibios_set_root_bus_speed() for better readability.
Signed-off-by: Yijing Wang
CC: Benjamin Herrenschmidt
CC: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Bjorn Helgaas
---
arch/powerpc/include/asm/machdep.h
Le 06/03/2015 01:28, Herbert Xu a écrit :
On Thu, Mar 05, 2015 at 06:21:01PM -0600, Kim Phillips wrote:
On Thu, 5 Mar 2015 17:46:05 +0100
Christophe Leroy wrote:
[15/17] crypto: talitos - Implementation of SEC1
...
[16/17] crypto: talitos - SEC1 bugs on 0 data hash
[17/17] crypto: talitos
41 matches
Mail list logo
