Le 06/03/2015 01:21, Kim Phillips a écrit :
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 - Update DT bindings with SEC1
This patchseries doesn't ap
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);
> > nodes_clear(node_
On Thu, 2015-03-05 at 17:12 -0500, Steven Rostedt wrote:
> A bug in ftrace was reported to me that affects ARM and ARM64 but not
> x86. Looking at the code it appears to affect PowerPC as well. So I
> booted up my old PA Semi, to give it a try. The last time I booted it
> was for a 3.17 kernel. Unf
On Thu, Mar 05, 2015 at 11:35:23AM +0200, Horia Geantă wrote:
>
> > Only potential problem is getting the crypto API to set the GFP_DMA
> > flag in the allocation request, but presumably a
> > CRYPTO_TFM_REQ_DMA crt_flag can be made to handle that.
>
> Right. And this flag would apply only to req
On Thu, Mar 05, 2015 at 11:54:52PM +, Mel Gorman wrote:
> Dave Chinner reported the following on https://lkml.org/lkml/2015/3/1/226
>
>Across the board the 4.0-rc1 numbers are much slower, and the
>degradation is far worse when using the large memory footprint
>configs. Perf points
On Thu, Mar 5, 2015 at 3:54 PM, Mel Gorman wrote:
> if (!prot_numa || !pmd_protnone(*pmd)) {
> - entry = pmdp_get_and_clear_notify(mm, addr, pmd);
> - entry = pmd_modify(entry, newprot);
> + /*
> +
On Thu, 5 Mar 2015 11:35:23 +0200
Horia Geantă wrote:
> On 3/4/2015 2:23 AM, Kim Phillips wrote:
> > On Tue, 3 Mar 2015 08:21:37 -0500
> > Martin Hicks wrote:
> >
> >> @@ -1170,6 +1237,8 @@ static struct talitos_edesc
> >> *talitos_edesc_alloc(struct device *dev,
> >>
On Tue, 3 Mar 2015 08:21:33 -0500
Martin Hicks wrote:
> There were multiple loops in a row, for each separate step of the
> initialization of the channels. Simplify to a single loop.
>
> Signed-off-by: Martin Hicks
> ---
Acked-by: Kim Phillips
Kim
__
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 - Update DT bindings wi
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 - Update DT bindings with SEC1
This patchseries doesn't apply, at least on top of Herbert's
cryptodev-
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 support this algorithm
combination (technically via the mode bit), thi
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
Kim
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozl
Dave Chinner reported the following on https://lkml.org/lkml/2015/3/1/226
Across the board the 4.0-rc1 numbers are much slower, and the
degradation is far worse when using the large memory footprint
configs. Perf points straight at the cause - this is from 4.0-rc1
on the "-o bhash=1010
The wrong value is being returned by change_huge_pmd since commit
10c1045f28e8 ("mm: numa: avoid unnecessary TLB flushes when setting
NUMA hinting entries") which allows a fallthrough that tries to adjust
non-existent PTEs. This patch corrects it.
Signed-off-by: Mel Gorman
---
mm/huge_memory.c |
Dave Chinner reported a problem due to excessive NUMA balancing activity and
bisected it. These are two patches that address two major issues with that
series. The first patch is almost certainly unrelated to what he saw due
to fact his vmstats showed no huge page activity but the fix is important.
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);
> nodes_clear(node_online_map);
> ...
> numa_register_memblks(...);
>
> arch/x
On 05.03.2015 [17:13:08 -0500], Tejun Heo wrote:
> On Thu, Mar 05, 2015 at 10:05:49AM -0800, Nishanth Aravamudan wrote:
> > While looking at this, I noticed that nr_node_ids is actually a
> > misnomer, it seems. It's not the number, but the maximum_node_id, as
> > with sparse NUMA nodes, you might
On Thu, Mar 05, 2015 at 03:21:35PM -0800, Nishanth Aravamudan wrote:
> So, do you agree with the general direction of my change? :)
Yeah, I mean it's an obvious bug fix. I don't know when or how it
should be set on powerpc but if the machine can't do NUMA node
hotplug, its node online and possibl
On 05.03.2015 [17:08:04 -0500], Tejun Heo wrote:
> Hello,
>
> On Thu, Mar 05, 2015 at 01:58:27PM -0800, David Rientjes wrote:
> > I'm not sure why this is being proposed as a powerpc patch and now a patch
> > for mem_cgroup_css_alloc(). In other words, why do we have to allocate
> > for all pos
On 05.03.2015 [13:58:27 -0800], David Rientjes wrote:
> On Fri, 6 Mar 2015, Michael Ellerman wrote:
>
> > > > diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> > > > index 0257a7d659ef..24de29b3651b 100644
> > > > --- a/arch/powerpc/mm/numa.c
> > > > +++ b/arch/powerpc/mm/numa.c
> > >
On 06.03.2015 [08:48:52 +1100], Michael Ellerman wrote:
> On Thu, 2015-03-05 at 13:16 -0800, David Rientjes wrote:
> > On Thu, 5 Mar 2015, Nishanth Aravamudan wrote:
> >
> > > diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> > > index 0257a7d659ef..24de29b3651b 100644
> > > --- a/arc
Hi David,
On 05.03.2015 [13:16:35 -0800], David Rientjes wrote:
> On Thu, 5 Mar 2015, Nishanth Aravamudan wrote:
>
> > diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> > index 0257a7d659ef..24de29b3651b 100644
> > --- a/arch/powerpc/mm/numa.c
> > +++ b/arch/powerpc/mm/numa.c
> > @@
On Thu, Mar 05, 2015 at 05:08:04PM -0500, Tejun Heo wrote:
> It can be argued that we should always stick to the online masks for
> allocation and iteration; however, that usually requires more
> complexity and the only cases where this mattered have been when the
> boot code got it wrong and faile
A bug in ftrace was reported to me that affects ARM and ARM64 but not
x86. Looking at the code it appears to affect PowerPC as well. So I
booted up my old PA Semi, to give it a try. The last time I booted it
was for a 3.17 kernel. Unfortunately, for 4.0-rc2 it crashed with:
Unable to handle kerne
On Thu, Mar 05, 2015 at 10:05:49AM -0800, Nishanth Aravamudan wrote:
> While looking at this, I noticed that nr_node_ids is actually a
> misnomer, it seems. It's not the number, but the maximum_node_id, as
> with sparse NUMA nodes, you might only have two NUMA nodes possible, but
> to make certain
Hello,
On Thu, Mar 05, 2015 at 01:58:27PM -0800, David Rientjes wrote:
> I'm not sure why this is being proposed as a powerpc patch and now a patch
> for mem_cgroup_css_alloc(). In other words, why do we have to allocate
> for all possible nodes? We should only be allocating for online nodes i
On Fri, 6 Mar 2015, Michael Ellerman wrote:
> > > diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> > > index 0257a7d659ef..24de29b3651b 100644
> > > --- a/arch/powerpc/mm/numa.c
> > > +++ b/arch/powerpc/mm/numa.c
> > > @@ -958,9 +958,17 @@ void __init initmem_init(void)
> > >
> > >
On Thu, 2015-03-05 at 13:16 -0800, David Rientjes wrote:
> On Thu, 5 Mar 2015, Nishanth Aravamudan wrote:
>
> > diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> > index 0257a7d659ef..24de29b3651b 100644
> > --- a/arch/powerpc/mm/numa.c
> > +++ b/arch/powerpc/mm/numa.c
> > @@ -958,9 +
On Thu, 5 Mar 2015, Nishanth Aravamudan wrote:
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index 0257a7d659ef..24de29b3651b 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -958,9 +958,17 @@ void __init initmem_init(void)
>
> memblock_dump_all(
On Wed, 2015-02-25 at 17:01 +0100, Wolfram Sang wrote:
> From: Wolfram Sang
>
> Here is the second version of the patch series to describe i2c adapter quirks
> in a generic way. For the motivation, please read description of patch 1. This
> is still RFC because I would like to do some more tests
Raghu noticed an issue with excessive memory allocation on power with a
simple cgroup test, specifically, in mem_cgroup_css_alloc ->
for_each_node -> alloc_mem_cgroup_per_zone_info(), which ends up blowing
up the kmalloc-2048 slab (to the order of 200MB for 400 cgroup
directories).
The underlying
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
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
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
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
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
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
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/drive
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
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
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 6c1f6f1..9f75ec9 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/
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
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
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 scat
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
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
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 e3a2
On 4 February 2015 at 07:33, Kevin Hao wrote:
> Since commit cd1e65044d44 ("of/device: Don't register disabled
> devices"), the disabled device will not be registered at all. So
> we don't need to do the check again in the platform device driver.
>
> And the check in the current code is useless ev
Hello Jamal,
On 03/05/2015 08:35 AM, Jamal Hadi Salim wrote:
> Hi Emil,
>
> On 03/05/15 08:48, Emil Medve wrote:
>
>> The intent is to upstream the entire suite of the DPAA drivers. All the
>> drivers are still WIP, but B/QMan have been already presented to the
>> upstream community and this is
Hi Emil,
On 03/05/15 08:48, Emil Medve wrote:
The intent is to upstream the entire suite of the DPAA drivers. All the
drivers are still WIP, but B/QMan have been already presented to the
upstream community and this is the first attempt to publish (some low
level code of) the FMan driver. As we
Hello Jamal,
On 03/05/2015 06:32 AM, Jamal Hadi Salim wrote:
> On 03/05/15 00:45, 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 architect
On 26 February 2015 at 13:08, Kevin Hao wrote:
> The PPC_OF is a ppc specific option which is used to mean that the
> firmware device tree access functions are available. Since all the
> ppc platforms have a device tree, it is aways set to 'y' for ppc.
> So it makes no sense to keep a such option
On 03/05/15 00:45, 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
sharing of networking inte
On Wed, Mar 04, 2015 at 09:05:04PM -0800, Nicolin Chen wrote:
> According to i.MX6 Series Reference Manual, the formula to calculate
> the sys clock is
Applied, thanks.
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc
On 3/4/2015 7:52 PM, Michael Ellerman wrote:
On Wed, 2015-03-04 at 07:46 -0400, Julian Margetson wrote:
Still stuck.
Problem still exist with 4.0.0-rc2 and I cant finish the bisect.
Triggered when using HDMI. No problem when using DVI.
[ 33.535692] Unable to handle kernel paging request for da
On 3/4/2015 2:23 AM, Kim Phillips wrote:
> On Tue, 3 Mar 2015 08:21:37 -0500
> Martin Hicks wrote:
>
>> @@ -1170,6 +1237,8 @@ static struct talitos_edesc
>> *talitos_edesc_alloc(struct device *dev,
>> edesc->dma_len,
>>
58 matches
Mail list logo