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 wsa+rene...@sang-engineering.com
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
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
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
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(...);
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 +958,17 @@
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
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 failed
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 mgor...@suse.de
---
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
On Tue, 3 Mar 2015 08:21:34 -0500
Martin Hicks m...@bork.org wrote:
This is properly defined in the md5 header file.
Signed-off-by: Martin Hicks m...@bork.org
---
Acked-by: Kim Phillips kim.phill...@freescale.com
Kim
___
Linuxppc-dev mailing
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 in
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
@@ -958,9
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
@@ -958,9 +958,17
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
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 only
On Fri, 20 Feb 2015 12:00:10 -0500
Martin Hicks m...@bork.org 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
Le 06/03/2015 01:21, Kim Phillips a écrit :
On Thu, 5 Mar 2015 17:46:05 +0100
Christophe Leroy christophe.le...@c-s.fr 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
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
---
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 possible
On Thu, Mar 5, 2015 at 3:54 PM, Mel Gorman mgor...@suse.de 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 17:46:05 +0100
Christophe Leroy christophe.le...@c-s.fr 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
On Thu, 5 Mar 2015 11:35:23 +0200
Horia Geantă horia.gea...@freescale.com wrote:
On 3/4/2015 2:23 AM, Kim Phillips wrote:
On Tue, 3 Mar 2015 08:21:37 -0500
Martin Hicks m...@bork.org wrote:
@@ -1170,6 +1237,8 @@ static struct talitos_edesc
*talitos_edesc_alloc(struct device *dev,
Do use zero_entry value to init the descriptors ptrs to zero instead of
writing 0 in each field
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/talitos.c
This patch refactors the handling of the input and output data that is quite
similar in several functions
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 163 ---
1 file changed, 85 insertions(+), 78 deletions(-)
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 christophe.le...@c-s.fr
---
drivers/crypto/talitos.h | 163
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
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
---
Move reset/init helpers init talitos2.h as they are specific to SEC2
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 19 ---
drivers/crypto/talitos2.h | 20
2 files changed, 20 insertions(+), 19 deletions(-)
diff
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 christophe.le...@c-s.fr
---
drivers/crypto/talitos.h | 85
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 christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 20
1 file changed, 16
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
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 christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 29 +++--
1 file
move sg_count() helper into talitos.h as it will be needed by SEC1 specific
functions
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 20
drivers/crypto/talitos.h | 21 +
2 files changed, 21 insertions(+), 20
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
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 christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 2 +-
drivers/crypto/talitos2.h | 5 +
2 files changed, 6 insertions(+), 1
Move hash chain handling into talitos2.h as only SEC2 has sg chaining
capatibility
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 34 --
drivers/crypto/talitos2.h | 34 ++
2 files changed,
Move interrupt related macros in talitos2.h as they are specific to SEC2
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 58 -
drivers/crypto/talitos2.h | 60 +++
2
This patch updates the documentation by including SEC1 into SEC2/3 doc
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
Documentation/devicetree/bindings/crypto/fsl-sec2.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
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
*
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
SEC1 bugs on 0 data hash, so we submit an already padded block representing 0
data
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 3 +++
drivers/crypto/talitos1.c | 21 +
drivers/crypto/talitos1.h | 4
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 christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 103 +-
drivers/crypto/talitos.h |
On 26 February 2015 at 13:08, Kevin Hao haoke...@gmail.com 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
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 igal.liber...@freescale.com
The Freescale Data Path Acceleration Architecture (DPAA) is a set of
hardware components on specific QorIQ P and T series multicore
processors.
On 3/4/2015 2:23 AM, Kim Phillips wrote:
On Tue, 3 Mar 2015 08:21:37 -0500
Martin Hicks m...@bork.org wrote:
@@ -1170,6 +1237,8 @@ static struct talitos_edesc
*talitos_edesc_alloc(struct device *dev,
edesc-dma_len,
On 03/05/15 00:45, Emil Medve wrote:
From: Igal Liberman igal.liber...@freescale.com
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
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
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
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
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 the
On 4 February 2015 at 07:33, Kevin Hao haoke...@gmail.com 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
On Tue, 3 Mar 2015 08:21:33 -0500
Martin Hicks m...@bork.org 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 m...@bork.org
---
Acked-by: Kim Phillips kim.phill...@freescale.com
On Thu, Mar 05, 2015 at 06:21:01PM -0600, Kim Phillips wrote:
On Thu, 5 Mar 2015 17:46:05 +0100
Christophe Leroy christophe.le...@c-s.fr wrote:
[15/17] crypto: talitos - Implementation of SEC1
...
[16/17] crypto: talitos - SEC1 bugs on 0 data hash
[17/17] crypto: talitos - Update DT
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_online_map);
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 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 request
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.
58 matches
Mail list logo
