Re: [PATCH v2 2/6] powernv:cpufreq: Create a powernv_cpu_to_core_mask() helper.
On 03/19/2014 05:07 AM, Benjamin Herrenschmidt wrote:
On Mon, 2014-03-10 at 16:40 +0530, Gautham R. Shenoy wrote:
From: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
Create a helper method that computes the cpumask corresponding to the
thread-siblings of a cpu. Use this for initializing the policy-cpus
mask for a given cpu.
(Original code written by Srivatsa S. Bhat. Gautham moved this to a
helper function!)
How does that differ from the existing entry in the sibling map which
you can obtain with the helper cpu_sibling_mask() ? (You probably want
to *copy* the mask of course but I don't see the need of re-creating
one from scratch).
The intent here was to have a sibling mask that is invariant of CPU
hotplug. cpu_sibling_mask is updated on every hotplug operation, and this
would break cpufreq, since policy-cpus has to be hotplug invariant.
This should have been noted in the changelog of patch 1 as well as this
patch. (The earlier (internal) versions of this patchset had the
description in the changelogs, but somehow it got dropped accidentally).
I'll work with Gautham and ensure that we have this important info
included in the changelog. Thanks for pointing it out!
Regards,
Srivatsa S. Bhat
Also, this should have been CCed to the cpufreq mailing list and maybe
the relevant maintainer too.
Cheers,
Ben.
Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
Signed-off-by: Gautham R. Shenoy e...@linux.vnet.ibm.com
---
drivers/cpufreq/powernv-cpufreq.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/cpufreq/powernv-cpufreq.c
b/drivers/cpufreq/powernv-cpufreq.c
index ab1551f..4cad727 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -115,6 +115,23 @@ static struct freq_attr *powernv_cpu_freq_attr[] = {
/* Helper routines */
+/**
+ * Sets the bits corresponding to the thread-siblings of cpu in its core
+ * in 'cpus'.
+ */
+static void powernv_cpu_to_core_mask(unsigned int cpu, cpumask_var_t cpus)
+{
+int base, i;
+
+base = cpu_first_thread_sibling(cpu);
+
+for (i = 0; i threads_per_core; i++) {
+cpumask_set_cpu(base + i, cpus);
+}
+
+return;
+}
+
/* Access helpers to power mgt SPR */
static inline unsigned long get_pmspr(unsigned long sprn)
@@ -180,13 +197,8 @@ static int powernv_set_freq(cpumask_var_t cpus,
unsigned int new_index)
static int powernv_cpufreq_cpu_init(struct cpufreq_policy *policy)
{
-int base, i;
-
#ifdef CONFIG_SMP
-base = cpu_first_thread_sibling(policy-cpu);
-
-for (i = 0; i threads_per_core; i++)
-cpumask_set_cpu(base + i, policy-cpus);
+powernv_cpu_to_core_mask(policy-cpu, policy-cpus);
#endif
policy-cpuinfo.transition_latency = 25000;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] fix dmaengine_unmap failure.
Hi Dan, In async_mult(...) of async_raid6_recov.c, the count 3 is used to request an unmap. However the to_cnt and bidi_cnt are both set to 1 and from_cnt to 0. Then while trying to do unmap, we are getting the wrong unmap from a different mempool. In this patch, the mempool is associated with the unmap structure instead of computing it again. By this way, it is guaranteed that the unmap is the same when we get and put the unmap data. BTW: the mempool is just used to manage the struct unmap, not the pages. Thanks, Xuelin Shi -Original Message- From: Dan Williams [mailto:dan.j.willi...@intel.com] Sent: 2014年3月19日 1:14 To: Shi Xuelin-B29237 Cc: Vinod Koul; linuxppc-dev; dmaeng...@vger.kernel.org Subject: Re: [PATCH] fix dmaengine_unmap failure. On Tue, Mar 18, 2014 at 1:32 AM, xuelin@freescale.com wrote: From: Xuelin Shi xuelin@freescale.com The count which is used to get_unmap_data maybe not the same as the count computed in dmaengine_unmap which causes to free data in a wrong pool. This patch fixes this issue by keeping the pool in unmap_data structure. Won't this free the entire count anyways? In what scenario is the count different at unmap? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] fix wrong usage of dmaengine_unmap_put in async_xxx
From: Xuelin Shi xuelin@freescale.com
dmaengine_unmap_put does below two things:
a) unmap pages for srcs and dests
b) free unmap struct
The unmap struct data is generated but only initialized while
other some dma contions are met, like dma alignment etc.
If the unmap data is not initialized, call dmaengine_unmap_put
will unmap some random data in unmap-addr[...]
Also call dmaengine_get_unmap_data immediatally after generating tx
is not correct. Maybe the tx has not been finished by DMA hardware
yet but the srcs and dests are dma unmapped.
This patch fixed above two issues by:
a) only generates unmap struct data when other dma conditions are met.
b) eliminates dmaengine_unmap_put when tx is generated because tx knowes
the best time to unmap it (in interrupt processing).
Signed-off-by: Xuelin Shi xuelin@freescale.com
---
crypto/async_tx/async_memcpy.c | 38
crypto/async_tx/async_pq.c | 191 ++---
crypto/async_tx/async_xor.c| 100 +++--
3 files changed, 175 insertions(+), 154 deletions(-)
diff --git a/crypto/async_tx/async_memcpy.c b/crypto/async_tx/async_memcpy.c
index f8c0b8d..578d1bd 100644
--- a/crypto/async_tx/async_memcpy.c
+++ b/crypto/async_tx/async_memcpy.c
@@ -52,10 +52,7 @@ async_memcpy(struct page *dest, struct page *src, unsigned
int dest_offset,
struct dma_async_tx_descriptor *tx = NULL;
struct dmaengine_unmap_data *unmap = NULL;
- if (device)
- unmap = dmaengine_get_unmap_data(device-dev, 2, GFP_NOIO);
-
- if (unmap is_dma_copy_aligned(device, src_offset, dest_offset, len))
{
+ if (device is_dma_copy_aligned(device, src_offset, dest_offset,
len)) {
unsigned long dma_prep_flags = 0;
if (submit-cb_fn)
@@ -63,17 +60,24 @@ async_memcpy(struct page *dest, struct page *src, unsigned
int dest_offset,
if (submit-flags ASYNC_TX_FENCE)
dma_prep_flags |= DMA_PREP_FENCE;
- unmap-to_cnt = 1;
- unmap-addr[0] = dma_map_page(device-dev, src, src_offset, len,
- DMA_TO_DEVICE);
- unmap-from_cnt = 1;
- unmap-addr[1] = dma_map_page(device-dev, dest, dest_offset,
len,
- DMA_FROM_DEVICE);
- unmap-len = len;
-
- tx = device-device_prep_dma_memcpy(chan, unmap-addr[1],
- unmap-addr[0], len,
- dma_prep_flags);
+ unmap = dmaengine_get_unmap_data(device-dev, 2, GFP_NOIO);
+ if (unmap) {
+ unmap-to_cnt = 1;
+ unmap-addr[0] = dma_map_page(device-dev, src,
+ src_offset, len,
+ DMA_TO_DEVICE);
+ unmap-from_cnt = 1;
+ unmap-addr[1] = dma_map_page(device-dev, dest,
+ dest_offset, len,
+ DMA_FROM_DEVICE);
+ unmap-len = len;
+
+ tx = device-device_prep_dma_memcpy(chan,
+ unmap-addr[1],
+ unmap-addr[0],
+ len,
+ dma_prep_flags);
+ }
}
if (tx) {
@@ -85,6 +89,8 @@ async_memcpy(struct page *dest, struct page *src, unsigned
int dest_offset,
void *dest_buf, *src_buf;
pr_debug(%s: (sync) len: %zu\n, __func__, len);
+ dmaengine_unmap_put(unmap);
+
/* wait for any prerequisite operations */
async_tx_quiesce(submit-depend_tx);
@@ -99,8 +105,6 @@ async_memcpy(struct page *dest, struct page *src, unsigned
int dest_offset,
async_tx_sync_epilog(submit);
}
- dmaengine_unmap_put(unmap);
-
return tx;
}
EXPORT_SYMBOL_GPL(async_memcpy);
diff --git a/crypto/async_tx/async_pq.c b/crypto/async_tx/async_pq.c
index d05327c..a25343c 100644
--- a/crypto/async_tx/async_pq.c
+++ b/crypto/async_tx/async_pq.c
@@ -175,10 +175,7 @@ async_gen_syndrome(struct page **blocks, unsigned int
offset, int disks,
BUG_ON(disks 255 || !(P(blocks, disks) || Q(blocks, disks)));
- if (device)
- unmap = dmaengine_get_unmap_data(device-dev, disks, GFP_NOIO);
-
- if (unmap
+ if (device
(src_cnt = dma_maxpq(device, 0) ||
dma_maxpq(device, DMA_PREP_CONTINUE) 0)
is_dma_pq_aligned(device, offset, 0, len)) {
@@ -194,42 +191,52 @@ async_gen_syndrome(struct page **blocks,
Re: [PATCH v2 2/6] powernv:cpufreq: Create a powernv_cpu_to_core_mask() helper.
On Wed, Mar 19, 2014 at 12:05:20PM +0530, Srivatsa S. Bhat wrote:
On 03/19/2014 05:07 AM, Benjamin Herrenschmidt wrote:
On Mon, 2014-03-10 at 16:40 +0530, Gautham R. Shenoy wrote:
From: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
Create a helper method that computes the cpumask corresponding to the
thread-siblings of a cpu. Use this for initializing the policy-cpus
mask for a given cpu.
(Original code written by Srivatsa S. Bhat. Gautham moved this to a
helper function!)
How does that differ from the existing entry in the sibling map which
you can obtain with the helper cpu_sibling_mask() ? (You probably want
to *copy* the mask of course but I don't see the need of re-creating
one from scratch).
The intent here was to have a sibling mask that is invariant of CPU
hotplug. cpu_sibling_mask is updated on every hotplug operation, and this
would break cpufreq, since policy-cpus has to be hotplug invariant.
This should have been noted in the changelog of patch 1 as well as this
patch. (The earlier (internal) versions of this patchset had the
description in the changelogs, but somehow it got dropped accidentally).
I'll work with Gautham and ensure that we have this important info
included in the changelog. Thanks for pointing it out!
I reused that part of the code because I was unaware of
cpu_sibling_mask()!
For implementing powernv_cpufreq_get(), cpu_sibling_mask() suffices
since we are using this mask as a parameter to
smp_call_function_any(), and hence are concerned only about the online
siblings.
I shall fix the changelog to reflect Srivatsa's reason for having a
mask that does not vary with cpu-hotplug.
Regards,
Srivatsa S. Bhat
Also, this should have been CCed to the cpufreq mailing list and maybe
the relevant maintainer too.
Ok. Will do it in the subsequent version.
Thanks for the review!
Cheers,
Ben.
Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
Signed-off-by: Gautham R. Shenoy e...@linux.vnet.ibm.com
---
drivers/cpufreq/powernv-cpufreq.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/cpufreq/powernv-cpufreq.c
b/drivers/cpufreq/powernv-cpufreq.c
index ab1551f..4cad727 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -115,6 +115,23 @@ static struct freq_attr *powernv_cpu_freq_attr[] = {
/* Helper routines */
+/**
+ * Sets the bits corresponding to the thread-siblings of cpu in its core
+ * in 'cpus'.
+ */
+static void powernv_cpu_to_core_mask(unsigned int cpu, cpumask_var_t cpus)
+{
+ int base, i;
+
+ base = cpu_first_thread_sibling(cpu);
+
+ for (i = 0; i threads_per_core; i++) {
+ cpumask_set_cpu(base + i, cpus);
+ }
+
+ return;
+}
+
/* Access helpers to power mgt SPR */
static inline unsigned long get_pmspr(unsigned long sprn)
@@ -180,13 +197,8 @@ static int powernv_set_freq(cpumask_var_t cpus,
unsigned int new_index)
static int powernv_cpufreq_cpu_init(struct cpufreq_policy *policy)
{
- int base, i;
-
#ifdef CONFIG_SMP
- base = cpu_first_thread_sibling(policy-cpu);
-
- for (i = 0; i threads_per_core; i++)
- cpumask_set_cpu(base + i, policy-cpus);
+ powernv_cpu_to_core_mask(policy-cpu, policy-cpus);
#endif
policy-cpuinfo.transition_latency = 25000;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC v9 2/6] dma: mpc512x: add support for peripheral transfers
Hello Andy
2014-03-14 13:47 GMT+04:00 Andy Shevchenko andriy.shevche...@linux.intel.com:
On Wed, 2014-03-12 at 15:47 +0400, Alexander Popov wrote:
+ case DMA_SLAVE_CONFIG:
+ /* Constraints:
+ * - only transfers between a peripheral device and
+ * memory are supported;
+ * - minimal transfer chunk is 4 bytes and consequently
+ * source and destination addresses must be 4-byte aligned
+ * and transfer size must be aligned on (4 * maxburst)
+ * boundary;
+ * - during the transfer RAM address is being incremented by
+ * the size of minimal transfer chunk;
+ * - peripheral port's address is constant during the
transfer.
+ */
+
+ cfg = (void *)arg;
+
+ if (!is_slave_direction(cfg-direction))
+ return -EINVAL;
As far as I understand the intention you have not to use direction field
in the dma_slave_config. It will be removed once.
+
+ if (cfg-src_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES
+ cfg-dst_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES)
+ return -EINVAL;
+
+ spin_lock_irqsave(mchan-lock, flags);
+
+ if (cfg-direction == DMA_DEV_TO_MEM) {
+ mchan-per_paddr = cfg-src_addr;
+ mchan-tcd_nunits = cfg-src_maxburst;
+ } else {
+ mchan-per_paddr = cfg-dst_addr;
+ mchan-tcd_nunits = cfg-dst_maxburst;
+ }
Ditto.
Excuse me, I don't understand this point.
I have to use cfg-direction because in case of DMA_DEV_TO_MEM
I use cfg-SRC_addr and cfg-SRC_maxburst and in case of
DMA_MEM_TO_DEV I use cfg-DST_addr and cfg-DST_maxburst.
Is it correct?
Best regards,
Alexander
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC v9 2/6] dma: mpc512x: add support for peripheral transfers
On Wed, Mar 19, 2014 at 05:26:47PM +0400, Alexander Popov wrote:
Hello Andy
2014-03-14 13:47 GMT+04:00 Andy Shevchenko
andriy.shevche...@linux.intel.com:
On Wed, 2014-03-12 at 15:47 +0400, Alexander Popov wrote:
+ case DMA_SLAVE_CONFIG:
+ /* Constraints:
+ * - only transfers between a peripheral device and
+ * memory are supported;
+ * - minimal transfer chunk is 4 bytes and consequently
+ * source and destination addresses must be 4-byte
aligned
+ * and transfer size must be aligned on (4 * maxburst)
+ * boundary;
+ * - during the transfer RAM address is being incremented by
+ * the size of minimal transfer chunk;
+ * - peripheral port's address is constant during the
transfer.
+ */
+
+ cfg = (void *)arg;
+
+ if (!is_slave_direction(cfg-direction))
+ return -EINVAL;
As far as I understand the intention you have not to use direction field
in the dma_slave_config. It will be removed once.
+
+ if (cfg-src_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES
+ cfg-dst_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES)
+ return -EINVAL;
+
+ spin_lock_irqsave(mchan-lock, flags);
+
+ if (cfg-direction == DMA_DEV_TO_MEM) {
+ mchan-per_paddr = cfg-src_addr;
+ mchan-tcd_nunits = cfg-src_maxburst;
+ } else {
+ mchan-per_paddr = cfg-dst_addr;
+ mchan-tcd_nunits = cfg-dst_maxburst;
+ }
Ditto.
Excuse me, I don't understand this point.
I have to use cfg-direction because in case of DMA_DEV_TO_MEM
I use cfg-SRC_addr and cfg-SRC_maxburst and in case of
DMA_MEM_TO_DEV I use cfg-DST_addr and cfg-DST_maxburst.
Is it correct?
You store the complete config for both source and destination.
Then based on the descriptor direction you can retrive the values from channel
context and program
This way you _dont_ need to fix the direction and can use it both ways!
--
~Vinod
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Tasks stuck in futex code (in 3.14-rc6)
Hi, When running specjbb on a power7 numa box, I am seeing java threads getting stuck in futex # ps -Ao pid,tt,user,fname,tmout,f,wchan | grep futex 14808 pts/0root java - 0 futex_wait_queue_me 14925 pts/0root java - 0 futex_wait_queue_me # stack traces, I see [ 1843.426591] Call Trace: [ 1843.426595] [c017101d74d0] [0020] 0x20 (unreliable) [ 1843.426601] [c017101d76a0] [c0014c50] .__switch_to+0x1e0/0x390 [ 1843.426607] [c017101d7750] [c06ed314] .__schedule+0x364/0x8c0 [ 1843.426613] [c017101d79d0] [c0139c28] .futex_wait_queue_me+0xf8/0x1a0 [ 1843.426619] [c017101d7a60] [c013afbc] .futex_wait+0x17c/0x2a0 [ 1843.426626] [c017101d7c10] [c013cee4] .do_futex+0x254/0xd80 [ 1843.426631] [c017101d7d60] [c013db2c] .SyS_futex+0x11c/0x1d0 [ 1843.426638] [c017101d7e30] [c0009efc] syscall_exit+0x0/0x7c [ 1843.426643] javaS 3fffa08b16a0 0 14812 14203 0x0080 [ 1843.426650] Call Trace: [ 1843.426653] [c0170c6034d0] [c01710b09cf8] 0xc01710b09cf8 (unreliable) [ 1843.426660] [c0170c6036a0] [c0014c50] .__switch_to+0x1e0/0x390 [ 1843.42] [c0170c603750] [c06ed314] .__schedule+0x364/0x8c0 [ 1843.426672] [c0170c6039d0] [c0139c28] .futex_wait_queue_me+0xf8/0x1a0 [ 1843.426679] [c0170c603a60] [c013afbc] .futex_wait+0x17c/0x2a0 [ 1843.453383] [c0170c603c10] [c013cee4] .do_futex+0x254/0xd80 [ 1843.453389] [c0170c603d60] [c013db2c] .SyS_futex+0x11c/0x1d0 [ 1843.453395] [c0170c603e30] [c0009efc] syscall_exit+0x0/0x7c [ 1843.453400] javaS 3fffa08b1a74 0 14813 14203 0x0080 [ 1843.453407] Call Trace: There are 332 tasks all stuck in futex_wait_queue_me(). I am able to reproduce this consistently. Infact I can reproduce this if the java_constraint is either node, socket, system. However I am not able to reproduce if java_constraint is set to core. I ran git bisect between v3.12 and v3.14-rc6 and found that https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b0c29f79ecea0b6fbcefc999e70f2843ae8306db commit b0c29f79ecea0b6fbcefc999e70f2843ae8306db Author: Davidlohr Bueso davidl...@hp.com Date: Sun Jan 12 15:31:25 2014 -0800 futexes: Avoid taking the hb-lock if there's nothing to wake up was the commit thats causing the threads to be stuck in futex. I reverted b0c29f79ecea0b6fbcefc999e70f2843ae8306db on top of v3.14-rc6 and confirmed that reverting the commit solved the problem. -- Thanks and Regards Srikar Dronamraju ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Tasks stuck in futex code (in 3.14-rc6)
On Wed, Mar 19, 2014 at 08:56:19PM +0530, Srikar Dronamraju wrote: There are 332 tasks all stuck in futex_wait_queue_me(). I am able to reproduce this consistently. Infact I can reproduce this if the java_constraint is either node, socket, system. However I am not able to reproduce if java_constraint is set to core. What's any of that mean? I ran git bisect between v3.12 and v3.14-rc6 and found that https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b0c29f79ecea0b6fbcefc999e70f2843ae8306db commit b0c29f79ecea0b6fbcefc999e70f2843ae8306db Author: Davidlohr Bueso davidl...@hp.com Date: Sun Jan 12 15:31:25 2014 -0800 futexes: Avoid taking the hb-lock if there's nothing to wake up was the commit thats causing the threads to be stuck in futex. I reverted b0c29f79ecea0b6fbcefc999e70f2843ae8306db on top of v3.14-rc6 and confirmed that reverting the commit solved the problem. Joy,.. let me look at that with ppc in mind. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: EDAC PCIe errors when scannning the bus
On Wed, Mar 19, 2014 at 01:46:37PM +0100, Valentin Longchamp wrote: Hello, We have a board that is based on Freescale's P2041 SoC. The boards has 2 PCIe buses with this topology: PCIe 0 --- PEX8505 switch --- 4 network devices PCIE 2 --- FPGA On 3.10.33 + a subset of the Freescale SDK 1.4 patches, both PCIe buses work well and we are able to use the devices on them. For each bus, I however keep getting EDAC PCIe errors at the very first stage of bus enumeration (please see the attached kernel log, with some debug output from arch/powerpc/kernel/pci-common.c and drivers/pci/probe.c) for both buses. My current understanding of the situation is such: since PCI_PROBE_NORMAL is used, pcibios_scan_phb() calls pci_scan_child_bus() that does a pci_scan_slot() on the bus for 32 slots. The first pci_scan_slot() is successful and it discovers the P2041's PCIe Controller. All the 31 other pci_scan_slot() calls generate an EDAC PCIe error, that is triggered by the configuration read transaction to read an hypothetical vendor ID of a device on the bus. This is relevant with that is reported by the EDAC error handler (all the 31 are the same): PCIE error(s) detected PCIE ERR_DR register: 0x0002 ICCA bit is set: Access to an illegal configuration space from PEX_CONFIG_ADDR/PEX_CONFIG_DATA was detected. PCIE ERR_CAP_STAT register: 0x8001 To is set: Transaction originated from PEX_CONFIG_ADDR/PEX_CONFIG_DATA. PCIE ERR_CAP_R0 register: 0x0800 FMT: 0b00, TYPE: 0b00100 (Config read I guess) PCIE ERR_CAP_R1 register: 0x PCIE ERR_CAP_R2 register: 0x PCIE ERR_CAP_R3 register: 0x Afterwards, pci_scan_child_bus() calls pcibios_fixup_bus (that maybe helps ?). From here, since the P2041's PCIe Controller is a bridge, pci_scan_bridge is called for this bus and all the devices are detected without having any configuration transaction causing EDAC errors. Has someone already observed such a behavior ? Why do these initial transaction generate an error ? What would be a possible fix to avoid these transaction errors for these 31 (unneded ?) pci_scan_slot() calls on the initial bus ? Best Regards, Valentin Hi Valentin, I've encountered similar problems on a P4080 based design (mine has additional machine checks that cause an oops). I haven't solved it yet, so I unfortunately can't offer you a fix. But I was told there are some errata workarounds that more or less could have an impact on PCIe behavior. Could you show me the output of U-Boot's errata command? Especially if the workarounds for A-004580 and A-004849 are in place. Johannes ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] fix dmaengine_unmap failure.
On Tue, Mar 18, 2014 at 11:39 PM, Xuelin Shi xuelin@freescale.com wrote: Hi Dan, In async_mult(...) of async_raid6_recov.c, the count 3 is used to request an unmap. However the to_cnt and bidi_cnt are both set to 1 and from_cnt to 0. Then while trying to do unmap, we are getting the wrong unmap from a different mempool. In this patch, the mempool is associated with the unmap structure instead of computing it again. By this way, it is guaranteed that the unmap is the same when we get and put the unmap data. BTW: the mempool is just used to manage the struct unmap, not the pages. I see, what about just storing the map_cnt at allocation time? It could be another byte in struct dmaengine_unmap_data rather than an 8 byte pointer. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Tasks stuck in futex code (in 3.14-rc6)
Infact I can reproduce this if the java_constraint is either node, socket, system. However I am not able to reproduce if java_constraint is set to core. What's any of that mean? Using the constraint, one can specify how many jvm instances should participate in the specjbb run. For example on a 4 node box, I can say 2 jvms per constraint with constraint set to node and specjbb will run with 8 instances of java. I was running with 1 jvm per constraint. But when I set the constraint to node/System, I keep seeing this problem. However if I set the constraint to core (which means running more instances of java), the problem is not seen. I kind of guess, the lesser the number of java instances the easier it is to reproduce. -- Thanks and Regards Srikar Dronamraju ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Tasks stuck in futex code (in 3.14-rc6)
On Wed, Mar 19, 2014 at 8:26 AM, Srikar Dronamraju sri...@linux.vnet.ibm.com wrote: I reverted b0c29f79ecea0b6fbcefc999e70f2843ae8306db on top of v3.14-rc6 and confirmed that reverting the commit solved the problem. Ok. I'll give Peter and Davidlohr a few days to perhaps find something obvious, but I guess we'll need to revert it from 3.14 and try again later unless some fix comes up quickly.. Oh well. Linus ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Tasks stuck in futex code (in 3.14-rc6)
On Wed, Mar 19, 2014 at 04:47:05PM +0100, Peter Zijlstra wrote:
I reverted b0c29f79ecea0b6fbcefc999e70f2843ae8306db on top of v3.14-rc6 and
confirmed that
reverting the commit solved the problem.
Joy,.. let me look at that with ppc in mind.
OK; so while pretty much all the comments from that patch are utter
nonsense (what was I thinking), I cannot actually find a real bug.
But could you try the below which replaces a control dependency with a
full barrier. The control flow is plenty convoluted that I think the
control barrier isn't actually valid anymore and that might indeed
explain the fail.
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -119,42 +119,32 @@
* sys_futex(WAIT, futex, val);
* futex_wait(futex, val);
*
- * waiters++;
- * mb(); (A) -- paired with -.
- * |
- * lock(hash_bucket(futex)); |
- * |
- * uval = *futex; |
- * |*futex = newval;
- * |sys_futex(WAKE, futex);
- * | futex_wake(futex);
- * |
- * `--- mb(); (B)
- * if (uval == val)
+ *
+ * lock(hash_bucket(futex)); (A)
+ *
+ * uval = *futex;
+ * *futex = newval;
+ * sys_futex(WAKE, futex);
+ * futex_wake(futex);
+ *
+ * if (uval == val) (B) smp_mb(); (D)
* queue();
- * unlock(hash_bucket(futex));
- * schedule(); if (waiters)
+ * unlock(hash_bucket(futex)); (C)
+ * schedule(); if (spin_is_locked(hb_lock) ||
+ *(smp_rmb(), !plist_empty))) (E)
* lock(hash_bucket(futex));
* wake_waiters(futex);
* unlock(hash_bucket(futex));
*
- * Where (A) orders the waiters increment and the futex value read -- this
- * is guaranteed by the head counter in the hb spinlock; and where (B)
- * orders the write to futex and the waiters read -- this is done by the
- * barriers in get_futex_key_refs(), through either ihold or atomic_inc,
- * depending on the futex type.
- *
- * This yields the following case (where X:=waiters, Y:=futex):
- *
- * X = Y = 0
- *
- * w[X]=1 w[Y]=1
- * MB MB
- * r[Y]=y r[X]=x
- *
- * Which guarantees that x==0 y==0 is impossible; which translates back into
- * the guarantee that we cannot both miss the futex variable change and the
- * enqueue.
+ *
+ * Because of the acquire (A) and release (C) the futex value load and the
+ * plist_add are guaranteed to be inside the locked region. Furthermore, the
+ * control dependency (B) ensures the futex load happens before the
plist_add().
+ *
+ * On the wakeup side, the full barrier (D) separates the futex value write
+ * from the hb_lock load, and matches with the control dependency. The rmb (E)
+ * separates the spin_is_locked() read and the plist_head_empty() read, such
+ * that ..., matches with the release barrier (C).
*/
#ifndef CONFIG_HAVE_FUTEX_CMPXCHG
@@ -250,7 +240,7 @@ static inline void futex_get_mm(union fu
/*
* Ensure futex_get_mm() implies a full barrier such that
* get_futex_key() implies a full barrier. This is relied upon
-* as full barrier (B), see the ordering comment above.
+* as full barrier (D), see the ordering comment above.
*/
smp_mb__after_atomic();
}
@@ -308,10 +298,10 @@ static void get_futex_key_refs(union fut
switch (key-both.offset (FUT_OFF_INODE|FUT_OFF_MMSHARED)) {
case FUT_OFF_INODE:
- ihold(key-shared.inode); /* implies MB (B) */
+ ihold(key-shared.inode); /* implies MB (D) */
break;
case FUT_OFF_MMSHARED:
- futex_get_mm(key); /* implies MB (B) */
+ futex_get_mm(key); /* implies MB (D) */
break;
}
}
@@ -385,7 +375,7 @@ get_futex_key(u32 __user *uaddr, int fsh
if (!fshared) {
key-private.mm = mm;
key-private.address = address;
- get_futex_key_refs(key); /* implies MB (B) */
+ get_futex_key_refs(key); /* implies MB (D) */
return 0;
}
@@ -492,7 +482,7 @@ get_futex_key(u32 __user *uaddr, int fsh
key-shared.pgoff = basepage_index(page);
}
- get_futex_key_refs(key); /* implies MB (B) */
+ get_futex_key_refs(key); /* implies MB (D) */
out:
unlock_page(page_head);
@@ -1604,7 +1594,7 @@ static inline struct futex_hash_bucket *
hb = hash_futex(q-key);
q-lock_ptr = hb-lock;
- spin_lock(hb-lock); /* implies MB (A) */
+
[PATCH] powerpc/le: big endian arguments for ppc_rtas()
The ppc_rtas() syscall allows userspace to interact directly with RTAS.
For the moment, it assumes every thing is big endian and returns either
EINVAL or EFAULT when called in a little endian environment.
As suggested by Benjamin, to avoid bugs when userspace wants to pass
a non 32 bit value to RTAS, it is far better to stick with a simple
rationale: ppc_rtas() should be called with a big endian rtas_args
structure.
With this patch, it is now up to userspace to forge big endian arguments,
as expected by RTAS.
Signed-off-by: Greg Kurz gk...@linux.vnet.ibm.com
---
Ben,
The chunk with the -1 return code check may look a bit pedantic. Please feel
free to kill it. :)
Cheers.
--
Greg
arch/powerpc/kernel/rtas.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 4cf674d..f386296 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -1013,12 +1013,13 @@ struct pseries_errorlog *get_pseries_errorlog(struct
rtas_error_log *log,
return NULL;
}
+/* We assume to be passed big endian arguments */
asmlinkage int ppc_rtas(struct rtas_args __user *uargs)
{
struct rtas_args args;
unsigned long flags;
char *buff_copy, *errbuf = NULL;
- int nargs;
+ int nargs, nret, token;
int rc;
if (!capable(CAP_SYS_ADMIN))
@@ -1027,10 +1028,13 @@ asmlinkage int ppc_rtas(struct rtas_args __user *uargs)
if (copy_from_user(args, uargs, 3 * sizeof(u32)) != 0)
return -EFAULT;
- nargs = args.nargs;
+ nargs = be32_to_cpu(args.nargs);
+ nret = be32_to_cpu(args.nret);
+ token = be32_to_cpu(args.token);
+
if (nargs ARRAY_SIZE(args.args)
- || args.nret ARRAY_SIZE(args.args)
- || nargs + args.nret ARRAY_SIZE(args.args))
+ || nret ARRAY_SIZE(args.args)
+ || nargs + nret ARRAY_SIZE(args.args))
return -EINVAL;
/* Copy in args. */
@@ -1038,14 +1042,14 @@ asmlinkage int ppc_rtas(struct rtas_args __user *uargs)
nargs * sizeof(rtas_arg_t)) != 0)
return -EFAULT;
- if (args.token == RTAS_UNKNOWN_SERVICE)
+ if (token == RTAS_UNKNOWN_SERVICE)
return -EINVAL;
args.rets = args.args[nargs];
- memset(args.rets, 0, args.nret * sizeof(rtas_arg_t));
+ memset(args.rets, 0, nret * sizeof(rtas_arg_t));
/* Need to handle ibm,suspend_me call specially */
- if (args.token == ibm_suspend_me_token) {
+ if (token == ibm_suspend_me_token) {
rc = rtas_ibm_suspend_me(args);
if (rc)
return rc;
@@ -1062,7 +1066,7 @@ asmlinkage int ppc_rtas(struct rtas_args __user *uargs)
/* A -1 return code indicates that the last command couldn't
be completed due to a hardware error. */
- if (args.rets[0] == -1)
+ if (be32_to_cpu(args.rets[0]) == -1)
errbuf = __fetch_rtas_last_error(buff_copy);
unlock_rtas(flags);
@@ -1077,7 +1081,7 @@ asmlinkage int ppc_rtas(struct rtas_args __user *uargs)
/* Copy out args. */
if (copy_to_user(uargs-args + nargs,
args.args + nargs,
-args.nret * sizeof(rtas_arg_t)) != 0)
+nret * sizeof(rtas_arg_t)) != 0)
return -EFAULT;
return 0;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Tasks stuck in futex code (in 3.14-rc6)
On Wed, 2014-03-19 at 18:08 +0100, Peter Zijlstra wrote: On Wed, Mar 19, 2014 at 04:47:05PM +0100, Peter Zijlstra wrote: I reverted b0c29f79ecea0b6fbcefc999e70f2843ae8306db on top of v3.14-rc6 and confirmed that reverting the commit solved the problem. Joy,.. let me look at that with ppc in mind. errr... just sat down to check email this morning. CC'ing Paul as for any subtle barrier issues. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC, v3] powerpc: Loading kernels over 8Mbytes without CONFIG_PIN_TLB
On Sun, Dec 15, 2013 at 04:09:57PM +0100, LEROY Christophe wrote:
Hereunder is a try to implement the sizing of the initial memory size based on
initial-mapped-area size given by uboot in r7.
As this has an impact on all powerpc platforms due to the need to provide the
info up to function setup_initial_memory_limit(), I'm not completly sure of
the
proper implementation.
Thanks to provide comments.
Today on the 8xx, the only way to load kernels whose size is greater than
8Mbytes is to activate CONFIG_PIN_TLB. Otherwise, the physical memory
initially
mapped is limited to 8Mbytes. This patch uses the size of initial memory
mapped
by the bootloader and given to the kernel through register r7.
This is done regardless of whether CONFIG_PIN_TLB is active or not. It allows
to
load big kernels (for instance when activating CONFIG_LOCKDEP_SUPPORT)
without
having to activate CONFIG_PIN_TLB.
Not-yet-signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant
parce que la protection avast! Antivirus est active.
http://www.avast.com
Index: linux/arch/powerpc/include/asm/mmu.h
===
--- linux/arch/powerpc/include/asm/mmu.h (revision 5484)
+++ linux/arch/powerpc/include/asm/mmu.h (copie de travail)
@@ -138,7 +138,8 @@
extern void early_init_mmu_secondary(void);
extern void setup_initial_memory_limit(phys_addr_t first_memblock_base,
-phys_addr_t first_memblock_size);
+phys_addr_t first_memblock_size,
+u64 init_mem_size);
What is the difference between first_memblock_size and init_mem_size, in
terms of what you expect setup_initial_memory_limit to do with them?
Can you just pass in min(first_memblock_size, init_mem_size), with the
non-ePAPR fallback handled in head_8xx.S (just load r30 with 8M instead
of zero)?
#ifdef CONFIG_PPC64
/* This is our real memory area size on ppc64 server, on embedded, we
Index: linux/arch/powerpc/kernel/head_8xx.S
===
--- linux/arch/powerpc/kernel/head_8xx.S (revision 5484)
+++ linux/arch/powerpc/kernel/head_8xx.S (copie de travail)
@@ -31,6 +31,8 @@
#include asm/asm-offsets.h
#include asm/ptrace.h
+#define EPAPR_MAGIC 0x65504150
+
/* Macro to make the code more readable. */
#ifdef CONFIG_8xx_CPU6
#define DO_8xx_CPU6(val, reg)\
@@ -77,10 +79,19 @@
.globl __start
__start:
mr r31,r3 /* save device tree ptr */
+ li r30,0
+ lis r8,EPAPR_MAGIC@h
+ ori r8,r8, EPAPR_MAGIC@l
+ cmpwcr0,r8, r6
Whitespace
+ bne 1f
+
+ mr r30,r7 /* save initial ram size */
+
/* We have to turn on the MMU right away so we get cache modes
* set correctly.
*/
+1:
bl initial_mmu
/* We now have the lower 8 Meg mapped into TLB entries, and the caches
@@ -717,6 +728,8 @@
*/
li r3,0
mr r4,r31
+ li r5,0
+ mr r6,r30
bl machine_init
bl MMU_init
@@ -841,11 +854,17 @@
ori r8, r8, MI_BOOTINIT|0x2 /* Inhibit cache -- Cort */
mtspr SPRN_MD_RPN, r8
+ /* Map two more 8M kernel data pages if needed
+ * We check how much memory is mapped by the bootloader
+ */
Whitespace
Index: linux/arch/powerpc/kernel/prom.c
===
--- linux/arch/powerpc/kernel/prom.c (revision 5484)
+++ linux/arch/powerpc/kernel/prom.c (copie de travail)
@@ -649,7 +649,7 @@
}
}
-void __init early_init_devtree(void *params)
+void __init early_init_devtree(void *params, u64 init_mem_size)
{
phys_addr_t limit;
@@ -697,7 +697,7 @@
/* make sure we've parsed cmdline for mem= before this */
if (memory_limit)
first_memblock_size = min_t(u64, first_memblock_size,
memory_limit);
- setup_initial_memory_limit(memstart_addr, first_memblock_size);
+ setup_initial_memory_limit(memstart_addr, first_memblock_size,
init_mem_size);
Line length.
Yes, I know there's an existing violation on the previous line. :-)
Index: linux/arch/powerpc/mm/init_32.c
===
--- linux/arch/powerpc/mm/init_32.c (revision 5484)
+++ linux/arch/powerpc/mm/init_32.c (copie de travail)
@@ -206,19 +206,16 @@
#ifdef CONFIG_8xx /* No 8xx specific .c file to put that in ... */
void setup_initial_memory_limit(phys_addr_t first_memblock_base,
- phys_addr_t first_memblock_size)
+ phys_addr_t first_memblock_size,
+ u64 init_mem_size)
{
RE: EDAC PCIe errors when scannning the bus
Hello, -Original Message- From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci- ow...@vger.kernel.org] On Behalf Of Valentin Longchamp Sent: Wednesday, March 19, 2014 5:47 AM To: linuxppc-dev@lists.ozlabs.org; linux-...@vger.kernel.org Subject: EDAC PCIe errors when scannning the bus Hello, We have a board that is based on Freescale's P2041 SoC. The boards has 2 PCIe buses with this topology: PCIe 0 --- PEX8505 switch --- 4 network devices PCIE 2 --- FPGA On 3.10.33 + a subset of the Freescale SDK 1.4 patches, both PCIe buses work well and we are able to use the devices on them. For each bus, I however keep getting EDAC PCIe errors at the very first stage of bus enumeration (please see the attached kernel log, with some debug output from arch/powerpc/kernel/pci-common.c and drivers/pci/probe.c) for both buses. My current understanding of the situation is such: since PCI_PROBE_NORMAL is used, pcibios_scan_phb() calls pci_scan_child_bus() that does a pci_scan_slot() on the bus for 32 slots. The first pci_scan_slot() is successful and it discovers the P2041's PCIe Controller. All the 31 other pci_scan_slot() calls generate an EDAC PCIe error, that is triggered by the configuration read transaction to read an hypothetical vendor ID of a device on the bus. This is relevant with that is reported by the EDAC error handler (all the 31 are the same): PCIE error(s) detected PCIE ERR_DR register: 0x0002 ICCA bit is set: Access to an illegal configuration space from PEX_CONFIG_ADDR/PEX_CONFIG_DATA was detected. PCIE ERR_CAP_STAT register: 0x8001 To is set: Transaction originated from PEX_CONFIG_ADDR/PEX_CONFIG_DATA. PCIE ERR_CAP_R0 register: 0x0800 FMT: 0b00, TYPE: 0b00100 (Config read I guess) PCIE ERR_CAP_R1 register: 0x PCIE ERR_CAP_R2 register: 0x PCIE ERR_CAP_R3 register: 0x Afterwards, pci_scan_child_bus() calls pcibios_fixup_bus (that maybe helps ?). From here, since the P2041's PCIe Controller is a bridge, pci_scan_bridge is called for this bus and all the devices are detected without having any configuration transaction causing EDAC errors. Has someone already observed such a behavior ? Why do these initial transaction generate an error ? What would be a possible fix to avoid these transaction errors for these 31 (unneded ?) pci_scan_slot() calls on the initial bus ? I see this too on my P5020 based platform. No fix yet, for now disabling the EDAC. Thanks, Rajat Best Regards, Valentin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [2/2] fsl/pci: The new pci suspend/resume implementation
On Tue, Jan 07, 2014 at 04:04:08PM +0800, Dongsheng Wang wrote:
From: Wang Dongsheng dongsheng.w...@freescale.com
The new suspend/resume implementation, send pme turnoff message
in suspend, and send pme exit message in resume.
Add a PME handler, to response PME message interrupt.
Change platform_driver-suspend/resume to syscore-suspend/resume.
pci-driver will call back EP device, to save EP state in
pci_pm_suspend_noirq, so we need to keep the link, until
pci_pm_suspend_noirq finish.
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
Is this patch OK to go in without patch 1/2? It's not clear whether that
was deemed incorrect (as in new patch coming) or unnecessary.
It would also be good if you submit with the explanation from
http://www.spinics.net/lists/linux-pci/msg27844.html in the commit
message.
-static int fsl_pci_probe(struct platform_device *pdev)
+#ifdef CONFIG_PM
+static irqreturn_t fsl_pci_pme_handle(int irq, void *dev_id)
{
- int ret;
- struct device_node *node;
+ struct pci_controller *hose = dev_id;
+ struct ccsr_pci __iomem *pci = hose-private_data;
+ u32 dr;
- node = pdev-dev.of_node;
- ret = fsl_add_bridge(pdev, fsl_pci_primary == node);
+ dr = in_be32(pci-pex_pme_mes_dr);
+ if (dr)
+ out_be32(pci-pex_pme_mes_dr, dr);
+ else
+ return IRQ_NONE;
- mpc85xx_pci_err_probe(pdev);
+ return IRQ_HANDLED;
+}
Why do you put some of the HANDLED path in the if statement, and some
outside?
Just do:
if (!dr)
return IRQ_NONE;
out_be32(...);
return IRQ_HANDLED;
+static int fsl_pci_pme_probe(struct pci_controller *hose)
+{
+ struct ccsr_pci __iomem *pci;
+ struct pci_dev *dev = hose-bus-self;
+ u16 pms;
+ int pme_irq;
+ int res;
+
+ /* PME Disable */
+ pci_read_config_word(dev, dev-pm_cap + PCI_PM_CTRL, pms);
+ pms = ~PCI_PM_CTRL_PME_ENABLE;
+ pci_write_config_word(dev, dev-pm_cap + PCI_PM_CTRL, pms);
+
+ pme_irq = irq_of_parse_and_map(hose-dn, 0);
+ if (!pme_irq) {
+ pr_warn(Failed to map PME interrupt.\n);
dev_err()
+
+ return -ENXIO;
+ }
+
+ res = devm_request_irq(hose-parent, pme_irq,
+ fsl_pci_pme_handle,
+ IRQF_DISABLED | IRQF_SHARED,
+ [PCI] PME, hose);
IRQF_DISABLED is a deprecated no-op.
+ if (res 0) {
+ pr_warn(Unable to requiest irq %d for PME\n, pme_irq);
dev_err() etc.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: clk: mpc85xx: Update the driver to align to new clock bindings
On Tue, Jan 21, 2014 at 09:32:45AM +0800, tang yuantian wrote:
From: Tang Yuantian yuantian.t...@freescale.com
The clock bindings for Freescale CoreNet platform are updated.
So, the driver needs to be updated accordingly.
The main changes include:
- Added a new node to present the input system clock
- Changed PLL and MUX's compatible string
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
---
drivers/clk/clk-ppc-corenet.c | 70 +--
1 file changed, 48 insertions(+), 22 deletions(-)
Acked-by: Scott Wood scottw...@freescale.com
Mike, does this need to go to linux-arm-ker...@lists.infradead.org as per
MAINTAINERS for drivers/clk?
diff --git a/drivers/clk/clk-ppc-corenet.c b/drivers/clk/clk-ppc-corenet.c
index c4f76ed..8b284be 100644
--- a/drivers/clk/clk-ppc-corenet.c
+++ b/drivers/clk/clk-ppc-corenet.c
@@ -27,7 +27,6 @@ struct cmux_clk {
#define CLKSEL_ADJUSTBIT(0)
#define to_cmux_clk(p) container_of(p, struct cmux_clk, hw)
-static void __iomem *base;
static unsigned int clocks_per_pll;
static int cmux_set_parent(struct clk_hw *hw, u8 idx)
@@ -100,7 +99,11 @@ static void __init core_mux_init(struct device_node *np)
pr_err(%s: could not allocate cmux_clk\n, __func__);
goto err_name;
}
- cmux_clk-reg = base + offset;
+ cmux_clk-reg = of_iomap(np, 0);
+ if (!cmux_clk-reg) {
+ pr_err(%s: could not map register\n, __func__);
+ goto err_clk;
+ }
dev_err? Though it looks like of_clk_init() makes it hard to pass a
reference to the parent device (or anything else but a function pointer
and device tree node) to the init function -- why?
node = of_find_compatible_node(NULL, NULL, fsl,p4080-clockgen);
if (node (offset = 0x80))
@@ -143,38 +146,39 @@ err_name:
static void __init core_pll_init(struct device_node *np)
{
- u32 offset, mult;
+ u32 mult;
int i, rc, count;
const char *clk_name, *parent_name;
struct clk_onecell_data *onecell_data;
struct clk **subclks;
+ void __iomem *base;
- rc = of_property_read_u32(np, reg, offset);
- if (rc) {
- pr_err(%s: could not get reg property\n, np-name);
+ base = of_iomap(np, 0);
+ if (!base) {
+ pr_err(clk-ppc: iomap error\n);
return;
}
/* get the multiple of PLL */
- mult = ioread32be(base + offset);
+ mult = ioread32be(base);
/* check if this PLL is disabled */
if (mult PLL_KILL) {
pr_debug(PLL:%s is disabled\n, np-name);
- return;
+ goto err_map;
}
mult = (mult 1) 0x3f;
parent_name = of_clk_get_parent_name(np, 0);
if (!parent_name) {
pr_err(PLL: %s must have a parent\n, np-name);
- return;
+ goto err_map;
}
count = of_property_count_strings(np, clock-output-names);
if (count 0 || count 4) {
pr_err(%s: clock is not supported\n, np-name);
- return;
+ goto err_map;
}
/* output clock number per PLL */
@@ -183,7 +187,7 @@ static void __init core_pll_init(struct device_node *np)
subclks = kzalloc(sizeof(struct clk *) * count, GFP_KERNEL);
if (!subclks) {
pr_err(%s: could not allocate subclks\n, __func__);
- return;
+ goto err_map;
}
onecell_data = kzalloc(sizeof(struct clk_onecell_data), GFP_KERNEL);
@@ -230,30 +234,52 @@ static void __init core_pll_init(struct device_node *np)
goto err_cell;
}
+ iounmap(base);
return;
err_cell:
kfree(onecell_data);
err_clks:
kfree(subclks);
+err_map:
+ iounmap(base);
+}
Consider devres -- is there a devres version of of_iomap()?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/4] ARCH: AUDIT: implement syscall_get_arch for all arches
For all arches which support audit implement syscall_get_arch()
They are all pretty easy and straight forward, stolen from how the call
to audit_syscall_entry() determines the arch.
Signed-off-by: Eric Paris epa...@redhat.com
Cc: linux-i...@vger.kernel.org
Cc: microblaze-ucli...@itee.uq.edu.au
Cc: linux-m...@linux-mips.org
Cc: li...@lists.openrisc.net
Cc: linux-par...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: sparcli...@vger.kernel.org
---
arch/ia64/include/asm/syscall.h | 6 ++
arch/microblaze/include/asm/syscall.h | 5 +
arch/mips/include/asm/syscall.h | 2 +-
arch/openrisc/include/asm/syscall.h | 5 +
arch/parisc/include/asm/syscall.h | 11 +++
arch/powerpc/include/asm/syscall.h| 12
arch/sparc/include/asm/syscall.h | 8
include/uapi/linux/audit.h| 1 +
8 files changed, 49 insertions(+), 1 deletion(-)
diff --git a/arch/ia64/include/asm/syscall.h b/arch/ia64/include/asm/syscall.h
index a7ff1c6..1d0b875 100644
--- a/arch/ia64/include/asm/syscall.h
+++ b/arch/ia64/include/asm/syscall.h
@@ -13,6 +13,7 @@
#ifndef _ASM_SYSCALL_H
#define _ASM_SYSCALL_H 1
+#include uapi/linux/audit.h
#include linux/sched.h
#include linux/err.h
@@ -79,4 +80,9 @@ static inline void syscall_set_arguments(struct task_struct
*task,
ia64_syscall_get_set_arguments(task, regs, i, n, args, 1);
}
+
+static inline int syscall_get_arch(void)
+{
+ return AUDIT_ARCH_IA64;
+}
#endif /* _ASM_SYSCALL_H */
diff --git a/arch/microblaze/include/asm/syscall.h
b/arch/microblaze/include/asm/syscall.h
index 9bc4317..53cfaf3 100644
--- a/arch/microblaze/include/asm/syscall.h
+++ b/arch/microblaze/include/asm/syscall.h
@@ -1,6 +1,7 @@
#ifndef __ASM_MICROBLAZE_SYSCALL_H
#define __ASM_MICROBLAZE_SYSCALL_H
+#include uapi/linux/audit.h
#include linux/kernel.h
#include linux/sched.h
#include asm/ptrace.h
@@ -99,4 +100,8 @@ static inline void syscall_set_arguments(struct task_struct
*task,
asmlinkage long do_syscall_trace_enter(struct pt_regs *regs);
asmlinkage void do_syscall_trace_leave(struct pt_regs *regs);
+static inline int syscall_get_arch(void)
+{
+ return AUDIT_ARCH_MICROBLAZE;
+}
#endif /* __ASM_MICROBLAZE_SYSCALL_H */
diff --git a/arch/mips/include/asm/syscall.h b/arch/mips/include/asm/syscall.h
index fc556d8..992b6ab 100644
--- a/arch/mips/include/asm/syscall.h
+++ b/arch/mips/include/asm/syscall.h
@@ -103,7 +103,7 @@ extern const unsigned long sysn32_call_table[];
static inline int syscall_get_arch(void)
{
- int arch = EM_MIPS;
+ int arch = AUDIT_ARCH_MIPS;
#ifdef CONFIG_64BIT
arch |= __AUDIT_ARCH_64BIT;
#endif
diff --git a/arch/openrisc/include/asm/syscall.h
b/arch/openrisc/include/asm/syscall.h
index b752bb6..2db9f1c 100644
--- a/arch/openrisc/include/asm/syscall.h
+++ b/arch/openrisc/include/asm/syscall.h
@@ -19,6 +19,7 @@
#ifndef __ASM_OPENRISC_SYSCALL_H__
#define __ASM_OPENRISC_SYSCALL_H__
+#include uapi/linux/audit.h
#include linux/err.h
#include linux/sched.h
@@ -71,4 +72,8 @@ syscall_set_arguments(struct task_struct *task, struct
pt_regs *regs,
memcpy(regs-gpr[3 + i], args, n * sizeof(args[0]));
}
+static inline int syscall_get_arch(void)
+{
+ return AUDIT_ARCH_OPENRISC;
+}
#endif
diff --git a/arch/parisc/include/asm/syscall.h
b/arch/parisc/include/asm/syscall.h
index 8bdfd2c..a5eba95 100644
--- a/arch/parisc/include/asm/syscall.h
+++ b/arch/parisc/include/asm/syscall.h
@@ -3,6 +3,8 @@
#ifndef _ASM_PARISC_SYSCALL_H_
#define _ASM_PARISC_SYSCALL_H_
+#include uapi/linux/audit.h
+#include linux/compat.h
#include linux/err.h
#include asm/ptrace.h
@@ -37,4 +39,13 @@ static inline void syscall_get_arguments(struct task_struct
*tsk,
}
}
+static inline int syscall_get_arch(void)
+{
+ int arch = AUDIT_ARCH_PARISC;
+#ifdef CONFIG_64BIT
+ if (!is_compat_task())
+ arch = AUDIT_ARCH_PARISC64;
+#endif
+ return arch;
+}
#endif /*_ASM_PARISC_SYSCALL_H_*/
diff --git a/arch/powerpc/include/asm/syscall.h
b/arch/powerpc/include/asm/syscall.h
index b54b2ad..4271544 100644
--- a/arch/powerpc/include/asm/syscall.h
+++ b/arch/powerpc/include/asm/syscall.h
@@ -13,6 +13,8 @@
#ifndef _ASM_SYSCALL_H
#define _ASM_SYSCALL_H 1
+#include uapi/linux/audit.h
+#include linux/compat.h
#include linux/sched.h
/* ftrace syscalls requires exporting the sys_call_table */
@@ -86,4 +88,14 @@ static inline void syscall_set_arguments(struct task_struct
*task,
memcpy(regs-gpr[3 + i], args, n * sizeof(args[0]));
}
+static inline int syscall_get_arch(void)
+{
+ int arch = AUDIT_ARCH_PPC;
+
+#ifdef CONFIG_PPC64
+ if (!is_32bit_task())
+ arch = AUDIT_ARCH_PPC64;
+#endif
+ return arch;
+}
#endif /* _ASM_SYSCALL_H */
diff --git a/arch/sparc/include/asm/syscall.h b/arch/sparc/include/asm/syscall.h
index 025a02a..fed3d51 100644
--- a/arch/sparc/include/asm/syscall.h
+++
Re: [PATCH] powerpc 32: Provides VIRT_CPU_ACCOUNTING
On Wed, 2014-03-19 at 22:52 +0100, Christophe Leroy wrote: This patch provides VIRT_CPU_ACCOUTING to PPC32 architecture. Unlike PPC64, PPC32 doesn't provide the PACA register. Therefore the implementation is similar to the one done in the IA64 architecture. It is based on additional information added to the Task Info structure. PACA isn't a register -- just a convention for how Linux uses a GPR. Maybe it's time to use it on PPC32 as well? Index: b/arch/powerpc/kernel/asm-offsets.c === --- b/arch/powerpc/kernel/asm-offsets.c (revision 5607) +++ b/arch/powerpc/kernel/asm-offsets.c (revision 5608) @@ -167,6 +167,10 @@ DEFINE(TI_PREEMPT, offsetof(struct thread_info, preempt_count)); DEFINE(TI_TASK, offsetof(struct thread_info, task)); DEFINE(TI_CPU, offsetof(struct thread_info, cpu)); + DEFINE(TI_AC_STAMP, offsetof(struct thread_info, ac_stamp)); + DEFINE(TI_AC_LEAVE, offsetof(struct thread_info, ac_leave)); + DEFINE(TI_AC_STIME, offsetof(struct thread_info, ac_stime)); + DEFINE(TI_AC_UTIME, offsetof(struct thread_info, ac_utime)); Doesn't this need to be protected by #ifdef CONFIG_VIRT_CPU_ACCOUNTING_NATIVE? #ifdef CONFIG_PPC64 DEFINE(DCACHEL1LINESIZE, offsetof(struct ppc64_caches, dline_size)); Index: b/arch/powerpc/include/asm/thread_info.h === --- b/arch/powerpc/include/asm/thread_info.h (revision 5607) +++ b/arch/powerpc/include/asm/thread_info.h (revision 5608) @@ -43,6 +43,12 @@ int cpu;/* cpu we're on */ int preempt_count; /* 0 = preemptable, 0 = BUG */ +#ifdef CONFIG_VIRT_CPU_ACCOUNTING_NATIVE + __u32 ac_stamp; + __u32 ac_leave; + __u32 ac_stime; + __u32 ac_utime; +#endif This isn't uapi; why not use u32? Plus, it should be made clear that this is only used on 32-bit. struct restart_block restart_block; unsigned long local_flags;/* private flags for thread */ @@ -58,6 +64,8 @@ .task = tsk, \ .exec_domain = default_exec_domain, \ .cpu = 0, \ + .ac_stime = 0, \ + .ac_utime = 0, \ Also needs to be ifdeffed -- which isn't going to work in a macro, so maybe remove the ifdef from the variable declarations, or just let the fields be initialized to zero by default. Or add PACA to 32-bit. :-) -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4] ARCH: AUDIT: implement syscall_get_arch for all arches
On Wed, Mar 19, 2014 at 3:04 PM, Eric Paris epa...@redhat.com wrote: For all arches which support audit implement syscall_get_arch() support audit -- is that AUDIT_ARCH? If so, alpha gained support recently, so I think this patch needs to handle alpha too? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc 32: Provides VIRT_CPU_ACCOUNTING
This patch provides VIRT_CPU_ACCOUTING to PPC32 architecture.
Unlike PPC64, PPC32 doesn't provide the PACA register. Therefore the
implementation is similar to the one done in the IA64 architecture.
It is based on additional information added to the Task Info structure.
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
Index: b/arch/powerpc/Kconfig
===
--- b/arch/powerpc/Kconfig (revision 5607)
+++ b/arch/powerpc/Kconfig (revision 5608)
@@ -138,6 +138,7 @@
select OLD_SIGSUSPEND
select OLD_SIGACTION if PPC32
select HAVE_DEBUG_STACKOVERFLOW
+ select HAVE_VIRT_CPU_ACCOUNTING
config EARLY_PRINTK
bool
Index: b/arch/powerpc/kernel/time.c
===
--- b/arch/powerpc/kernel/time.c(revision 5607)
+++ b/arch/powerpc/kernel/time.c(revision 5608)
@@ -162,7 +162,9 @@
cputime_t cputime_one_jiffy;
+#ifdef CONFIG_PPC_SPLPAR
void (*dtl_consumer)(struct dtl_entry *, u64);
+#endif
static void calc_cputime_factors(void)
{
@@ -178,6 +180,7 @@
__cputime_clockt_factor = res.result_low;
}
+#ifdef CONFIG_PPC64
/*
* Read the SPURR on systems that have it, otherwise the PURR,
* or if that doesn't exist return the timebase value passed in.
@@ -190,6 +193,7 @@
return mfspr(SPRN_PURR);
return tb;
}
+#endif
#ifdef CONFIG_PPC_SPLPAR
@@ -291,6 +295,7 @@
* Account time for a transition between system, hard irq
* or soft irq state.
*/
+#ifdef CONFIG_PPC64
static u64 vtime_delta(struct task_struct *tsk,
u64 *sys_scaled, u64 *stolen)
{
@@ -377,7 +382,70 @@
get_paca()-utime_sspurr = 0;
account_user_time(tsk, utime, utimescaled);
}
+#else
+void vtime_account_user(struct task_struct *tsk)
+{
+ cputime_t delta_utime;
+ struct thread_info *ti = task_thread_info(tsk);
+
+ if (ti-ac_utime) {
+ delta_utime = ti-ac_utime;
+ account_user_time(tsk, delta_utime, delta_utime);
+ ti-ac_utime = 0;
+ }
+}
+
+/*
+ * Called from the context switch with interrupts disabled, to charge all
+ * accumulated times to the current process, and to prepare accounting on
+ * the next process.
+ */
+void arch_vtime_task_switch(struct task_struct *prev)
+{
+ struct thread_info *pi = task_thread_info(prev);
+ struct thread_info *ni = task_thread_info(current);
+
+ ni-ac_stamp = pi-ac_stamp;
+ ni-ac_stime = ni-ac_utime = 0;
+}
+
+/*
+ * Account time for a transition between system, hard irq or soft irq state.
+ * Note that this function is called with interrupts enabled.
+ */
+static cputime_t vtime_delta(struct task_struct *tsk)
+{
+ struct thread_info *ti = task_thread_info(tsk);
+ __u32 delta_stime;
+ __u32 now;
+
+ WARN_ON_ONCE(!irqs_disabled());
+
+ now = mftbl();
+
+ delta_stime = ti-ac_stime + (now - ti-ac_stamp);
+ ti-ac_stime = 0;
+ ti-ac_stamp = now;
+
+ return (cputime_t)delta_stime;
+}
+
+void vtime_account_system(struct task_struct *tsk)
+{
+ cputime_t delta = vtime_delta(tsk);
+
+ account_system_time(tsk, 0, delta, delta);
+}
+EXPORT_SYMBOL_GPL(vtime_account_system);
+
+void vtime_account_idle(struct task_struct *tsk)
+{
+ account_idle_time(vtime_delta(tsk));
+}
+
+#endif
+
#else /* ! CONFIG_VIRT_CPU_ACCOUNTING_NATIVE */
#define calc_cputime_factors()
#endif
@@ -871,6 +939,8 @@
ppc_proc_freq / 100, ppc_proc_freq % 100);
}
+ mttbl(0);
+ mttbu(0);
tb_ticks_per_jiffy = ppc_tb_freq / HZ;
tb_ticks_per_sec = ppc_tb_freq;
tb_ticks_per_usec = ppc_tb_freq / 100;
Index: b/arch/powerpc/kernel/entry_32.S
===
--- b/arch/powerpc/kernel/entry_32.S(revision 5607)
+++ b/arch/powerpc/kernel/entry_32.S(revision 5608)
@@ -177,6 +177,12 @@
addir12,r12,-1
stw r12,4(r11)
#endif
+#ifdef CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
+ CURRENT_THREAD_INFO(r9, r1)
+ tophys(r9, r9)
+ ACCOUNT_CPU_USER_ENTRY(r9, r11, r12)
+#endif
+
b 3f
2: /* if from kernel, check interrupted DOZE/NAP mode and
@@ -406,6 +412,13 @@
lwarx r7,0,r1
END_FTR_SECTION_IFSET(CPU_FTR_NEED_PAIRED_STWCX)
stwcx. r0,0,r1 /* to clear the reservation */
+#ifdef CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
+ andi. r4,r8,MSR_PR
+ beq 3f
+ CURRENT_THREAD_INFO(r4, r1)
+ ACCOUNT_CPU_USER_EXIT(r4, r5, r7)
+3:
+#endif
lwz r4,_LINK(r1)
lwz r5,_CCR(r1)
mtlrr4
@@ -841,6 +854,10 @@
andis. r10,r0,DBCR0_IDM@h
bnel- load_dbcr0
#endif
+#ifdef CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
+ CURRENT_THREAD_INFO(r9, r1)
+ ACCOUNT_CPU_USER_EXIT(r9, r10, r11)
+#endif
Re: [1/2, v9] powerpc/mpc85xx:Add initial device tree support of T104x
On Sat, Jan 25, 2014 at 05:10:59PM +0530, Prabhakar Kushwaha wrote:
+ corenet-cf@18000 {
+ compatible = fsl,corenet-cf;
+ reg = 0x18000 0x1000;
+ interrupts = 16 2 1 31;
+ fsl,ccf-num-csdids = 32;
+ fsl,ccf-num-snoopids = 32;
+ };
I know this isn't a new problem, but this needs a binding -- and a
different compatible from p4080-era CCF. AFAICT it's a completely
different programming model, and even the block version registers weren't
present in the original version.
+/include/ qoriq-mpic.dtsi
+
+ guts: global-utilities@e {
+ compatible = fsl,t1040-device-config,
fsl,qoriq-device-config-2.0;
+ reg = 0xe 0xe00;
+ fsl,has-rstcr;
+ fsl,liodn-bits = 12;
+ };
+
+ clockgen: global-utilities@e1000 {
+ compatible = fsl,t1040-clockgen, fsl,qoriq-clockgen-2.0,
+fixed-clock;
+ ranges = 0x0 0xe1000 0x1000;
+ clock-frequency = 1;
Why is clock-frequency hardcoded here rather than supplied by U-Boot?
Especially since this is an SoC file, not a board file.
+ reg = 0xe1000 0x1000;
+ clock-output-names = sysclk;
+ #address-cells = 1;
+ #size-cells = 1;
clock-output-names and fixed-clock doesn't belong on this node.
+
+ sysclk: sysclk {
+ #clock-cells = 0;
+ compatible = fsl,qoriq-sysclk-2.0;
+ clock-output-names = sysclk;
+ };
+
+
+ pll0: pll0@800 {
+ #clock-cells = 1;
+ reg = 0x800 4;
+ compatible = fsl,qoriq-core-pll-2.0;
+ clocks = clockgen;
+ clock-output-names = pll0, pll0-div2, pll0-div4;
+ };
+
+ pll1: pll1@820 {
+ #clock-cells = 1;
+ reg = 0x820 4;
+ compatible = fsl,qoriq-core-pll-2.0;
+ clocks = clockgen;
+ clock-output-names = pll1, pll1-div2, pll1-div4;
+ };
clocks should point to sysclk.
+ display@18 {
+ compatible = fsl,t1040-diu, fsl,diu;
+ reg = 0x18 1000;
+ interrupts = 74 2 0 0;
+ };
+
+/include/ qoriq-sata2-0.dtsi
+sata@22 {
+ fsl,iommu-parent = pamu0;
+ fsl,liodn-reg = guts 0x550; /* SATA1LIODNR */
+};
+/include/ qoriq-sata2-1.dtsi
+sata@221000 {
+ fsl,iommu-parent = pamu0;
+ fsl,liodn-reg = guts 0x554; /* SATA2LIODNR */
+};
+/include/ qoriq-sec5.0-0.dtsi
+};
Whitespace
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/config: Remove unnecssary CONFIG_FSL_IFC
On Sat, Jan 25, 2014 at 05:53:32PM +0530, Prabhakar Kushwaha wrote: CONFIG_FSL_IFC gets enabled by Kconfig dependancies. So remove unnecssary define from the defconfigs Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com --- arch/powerpc/configs/corenet64_smp_defconfig |1 - arch/powerpc/configs/mpc85xx_defconfig |1 - arch/powerpc/configs/mpc85xx_smp_defconfig |1 - 3 files changed, 3 deletions(-) I'll apply this, but FSL_IFC really should be made user-selectable without needing to enable NAND support, since it also provides error reporting for NOR and GPCM. Also, when submitting patches like this, it's best to mention that it's the output of running savedefconfig (and if that isn't how the patch was generated, do it that way instead). -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/4] ARCH: AUDIT: audit_syscall_entry() should not require the arch
We have a function where the arch can be queried, syscall_get_arch(). So rather than have every single piece of arch specific code use and/or duplicate syscall_get_arch(), just have the audit code use the syscall_get_arch() code. Signed-off-by: Eric Paris epa...@redhat.com Cc: linux-al...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-i...@vger.kernel.org Cc: microblaze-ucli...@itee.uq.edu.au Cc: linux-m...@linux-mips.org Cc: li...@lists.openrisc.net Cc: linux-par...@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-s...@vger.kernel.org Cc: linux...@vger.kernel.org Cc: sparcli...@vger.kernel.org Cc: user-mode-linux-de...@lists.sourceforge.net Cc: linux-xte...@linux-xtensa.org Cc: x...@kernel.org --- arch/alpha/kernel/ptrace.c | 2 +- arch/arm/kernel/ptrace.c| 4 ++-- arch/ia64/kernel/ptrace.c | 2 +- arch/microblaze/kernel/ptrace.c | 3 +-- arch/mips/kernel/ptrace.c | 4 +--- arch/openrisc/kernel/ptrace.c | 3 +-- arch/parisc/kernel/ptrace.c | 9 +++-- arch/powerpc/kernel/ptrace.c| 7 ++- arch/s390/kernel/ptrace.c | 4 +--- arch/sh/kernel/ptrace_32.c | 14 +- arch/sh/kernel/ptrace_64.c | 17 + arch/sparc/kernel/ptrace_64.c | 9 ++--- arch/um/kernel/ptrace.c | 3 +-- arch/x86/kernel/ptrace.c| 8 ++-- arch/x86/um/asm/ptrace.h| 4 arch/xtensa/kernel/ptrace.c | 2 +- include/linux/audit.h | 7 --- 17 files changed, 25 insertions(+), 77 deletions(-) diff --git a/arch/alpha/kernel/ptrace.c b/arch/alpha/kernel/ptrace.c index 86d8351..d9ee817 100644 --- a/arch/alpha/kernel/ptrace.c +++ b/arch/alpha/kernel/ptrace.c @@ -321,7 +321,7 @@ asmlinkage unsigned long syscall_trace_enter(void) if (test_thread_flag(TIF_SYSCALL_TRACE) tracehook_report_syscall_entry(current_pt_regs())) ret = -1UL; - audit_syscall_entry(AUDIT_ARCH_ALPHA, regs-r0, regs-r16, regs-r17, regs-r18, regs-r19); + audit_syscall_entry(regs-r0, regs-r16, regs-r17, regs-r18, regs-r19); return ret ?: current_pt_regs()-r0; } diff --git a/arch/arm/kernel/ptrace.c b/arch/arm/kernel/ptrace.c index 0dd3b79..c9d2b34 100644 --- a/arch/arm/kernel/ptrace.c +++ b/arch/arm/kernel/ptrace.c @@ -943,8 +943,8 @@ asmlinkage int syscall_trace_enter(struct pt_regs *regs, int scno) if (test_thread_flag(TIF_SYSCALL_TRACEPOINT)) trace_sys_enter(regs, scno); - audit_syscall_entry(AUDIT_ARCH_ARM, scno, regs-ARM_r0, regs-ARM_r1, - regs-ARM_r2, regs-ARM_r3); + audit_syscall_entry(scno, regs-ARM_r0, regs-ARM_r1, regs-ARM_r2, + regs-ARM_r3); return scno; } diff --git a/arch/ia64/kernel/ptrace.c b/arch/ia64/kernel/ptrace.c index b7a5fff..6f54d51 100644 --- a/arch/ia64/kernel/ptrace.c +++ b/arch/ia64/kernel/ptrace.c @@ -1219,7 +1219,7 @@ syscall_trace_enter (long arg0, long arg1, long arg2, long arg3, ia64_sync_krbs(); - audit_syscall_entry(AUDIT_ARCH_IA64, regs.r15, arg0, arg1, arg2, arg3); + audit_syscall_entry(regs.r15, arg0, arg1, arg2, arg3); return 0; } diff --git a/arch/microblaze/kernel/ptrace.c b/arch/microblaze/kernel/ptrace.c index 39cf508..bb10637 100644 --- a/arch/microblaze/kernel/ptrace.c +++ b/arch/microblaze/kernel/ptrace.c @@ -147,8 +147,7 @@ asmlinkage long do_syscall_trace_enter(struct pt_regs *regs) */ ret = -1L; - audit_syscall_entry(EM_MICROBLAZE, regs-r12, regs-r5, regs-r6, - regs-r7, regs-r8); + audit_syscall_entry(regs-r12, regs-r5, regs-r6, regs-r7, regs-r8); return ret ?: regs-r12; } diff --git a/arch/mips/kernel/ptrace.c b/arch/mips/kernel/ptrace.c index 65ba622..c06bb82 100644 --- a/arch/mips/kernel/ptrace.c +++ b/arch/mips/kernel/ptrace.c @@ -671,9 +671,7 @@ asmlinkage void syscall_trace_enter(struct pt_regs *regs) if (unlikely(test_thread_flag(TIF_SYSCALL_TRACEPOINT))) trace_sys_enter(regs, regs-regs[2]); - audit_syscall_entry(syscall_get_arch(), - regs-regs[2], - regs-regs[4], regs-regs[5], + audit_syscall_entry(regs-regs[2], regs-regs[4], regs-regs[5], regs-regs[6], regs-regs[7]); } diff --git a/arch/openrisc/kernel/ptrace.c b/arch/openrisc/kernel/ptrace.c index 71a2a0c..4f59fa4 100644 --- a/arch/openrisc/kernel/ptrace.c +++ b/arch/openrisc/kernel/ptrace.c @@ -187,8 +187,7 @@ asmlinkage long do_syscall_trace_enter(struct pt_regs *regs) */ ret = -1L; - audit_syscall_entry(AUDIT_ARCH_OPENRISC, regs-gpr[11], - regs-gpr[3], regs-gpr[4], + audit_syscall_entry(regs-gpr[11], regs-gpr[3], regs-gpr[4], regs-gpr[5], regs-gpr[6]); return ret ? : regs-gpr[11];
Re: [PATCH 3/4] ARCH: AUDIT: implement syscall_get_arch for all arches
On Wed, 2014-03-19 at 15:19 -0700, Matt Turner wrote: On Wed, Mar 19, 2014 at 3:04 PM, Eric Paris epa...@redhat.com wrote: For all arches which support audit implement syscall_get_arch() support audit -- is that AUDIT_ARCH? If so, alpha gained support recently, so I think this patch needs to handle alpha too? Absolutely right. I broke Alpha (in the next patch). Will fix. -Eric ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v2, 2/2] powerpc/mpc85xx: add support for Keymile's kmcoge4 board
On Tue, Feb 11, 2014 at 12:50:07PM +0100, Valentin Longchamp wrote:
+ reset_cpld@1,0 {
+ interrupt-controller;
+ #interrupt-cells = 2;
+ reg = 1 0 0x80;
+ interrupt-parent = mpic;
+ interrupts =
+ 4 1 0 0
+ 5 1 0 0;
+ };
+
+ chassis_mgmt@3,0 {
+ interrupt-controller;
+ #interrupt-cells = 2;
+ reg = 3 0 0x100;
+ interrupt-parent = mpic;
+ interrupts = 6 1 0 0;
+ };
Dashes are preferred to underscores in device trees.
More importantly, these nodes need proper compatibles and bindings. Once
that's done, the name for the nodes should probably be
board_control@whatever for both.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
3.16.6 build error: swsusp_booke.S:85: Error: invalid sprg number
Platform: Freescale p4080--e500mc , Suggestions welcome . /bin/sh arch/powerpc/kernel/systbl_chk.sh arch/powerpc/kernel/systbl_chk.i make -f scripts/Makefile.build obj=arch/powerpc/kernel/vdso32 gcc -mbig-endian -m32 -Wp,-MD,arch/powerpc/kernel/.swsusp_booke.o.d -nostdinc -isystem /usr/lib/gcc/ppc64-redhat-linux/4.8.2/include -I/root/linux-3.13.6/arch/powerpc/include -Iarch/powerpc/include/generated -Iinclude -I/root/linux-3.13.6/arch/powerpc/include/uapi -Iarch/powerpc/include/generated/uapi -I/root/linux-3.13.6/include/uapi -Iinclude/generated/uapi -include /root/linux-3.13.6/include/linux/kconfig.h -D__KERNEL__ -Iarch/powerpc -D__ASSEMBLY__ -Iarch/powerpc -gdwarf-2 -c -o arch/powerpc/kernel/swsusp_booke.o arch/powerpc/kernel/swsusp_booke.S arch/powerpc/kernel/swsusp_booke.S: Assembler messages: arch/powerpc/kernel/swsusp_booke.S:85: Error: invalid sprg number arch/powerpc/kernel/swsusp_booke.S:87: Error: invalid sprg number -- *Regards,* * John.* *--* *o* Energy-efficiency is #1 reason data centers look to expand. -- Digital Realty Trust *o* Green Data Centers spending to increase 300% worldwide by 2016. -- Pike Research *o *Data Centers have become as vital to the functioni ng of society as power stations. -- The Economist ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: clk: mpc85xx: Update the driver to align to new clock bindings
Quoting Scott Wood (2014-03-19 14:52:23)
On Tue, Jan 21, 2014 at 09:32:45AM +0800, tang yuantian wrote:
From: Tang Yuantian yuantian.t...@freescale.com
The clock bindings for Freescale CoreNet platform are updated.
So, the driver needs to be updated accordingly.
The main changes include:
- Added a new node to present the input system clock
- Changed PLL and MUX's compatible string
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
---
drivers/clk/clk-ppc-corenet.c | 70
+--
1 file changed, 48 insertions(+), 22 deletions(-)
Acked-by: Scott Wood scottw...@freescale.com
Mike, does this need to go to linux-arm-ker...@lists.infradead.org as per
MAINTAINERS for drivers/clk?
Nope, I should probably change that to LKML just be politically correct.
The important thing is to Cc me (which the original poster did) and ping
me if I don't review your patch after a week or two (which you did).
This patch looks great and I've taken it into clk-next.
Thanks,
Mike
diff --git a/drivers/clk/clk-ppc-corenet.c b/drivers/clk/clk-ppc-corenet.c
index c4f76ed..8b284be 100644
--- a/drivers/clk/clk-ppc-corenet.c
+++ b/drivers/clk/clk-ppc-corenet.c
@@ -27,7 +27,6 @@ struct cmux_clk {
#define CLKSEL_ADJUSTBIT(0)
#define to_cmux_clk(p) container_of(p, struct cmux_clk, hw)
-static void __iomem *base;
static unsigned int clocks_per_pll;
static int cmux_set_parent(struct clk_hw *hw, u8 idx)
@@ -100,7 +99,11 @@ static void __init core_mux_init(struct device_node *np)
pr_err(%s: could not allocate cmux_clk\n, __func__);
goto err_name;
}
- cmux_clk-reg = base + offset;
+ cmux_clk-reg = of_iomap(np, 0);
+ if (!cmux_clk-reg) {
+ pr_err(%s: could not map register\n, __func__);
+ goto err_clk;
+ }
dev_err? Though it looks like of_clk_init() makes it hard to pass a
reference to the parent device (or anything else but a function pointer
and device tree node) to the init function -- why?
node = of_find_compatible_node(NULL, NULL, fsl,p4080-clockgen);
if (node (offset = 0x80))
@@ -143,38 +146,39 @@ err_name:
static void __init core_pll_init(struct device_node *np)
{
- u32 offset, mult;
+ u32 mult;
int i, rc, count;
const char *clk_name, *parent_name;
struct clk_onecell_data *onecell_data;
struct clk **subclks;
+ void __iomem *base;
- rc = of_property_read_u32(np, reg, offset);
- if (rc) {
- pr_err(%s: could not get reg property\n, np-name);
+ base = of_iomap(np, 0);
+ if (!base) {
+ pr_err(clk-ppc: iomap error\n);
return;
}
/* get the multiple of PLL */
- mult = ioread32be(base + offset);
+ mult = ioread32be(base);
/* check if this PLL is disabled */
if (mult PLL_KILL) {
pr_debug(PLL:%s is disabled\n, np-name);
- return;
+ goto err_map;
}
mult = (mult 1) 0x3f;
parent_name = of_clk_get_parent_name(np, 0);
if (!parent_name) {
pr_err(PLL: %s must have a parent\n, np-name);
- return;
+ goto err_map;
}
count = of_property_count_strings(np, clock-output-names);
if (count 0 || count 4) {
pr_err(%s: clock is not supported\n, np-name);
- return;
+ goto err_map;
}
/* output clock number per PLL */
@@ -183,7 +187,7 @@ static void __init core_pll_init(struct device_node *np)
subclks = kzalloc(sizeof(struct clk *) * count, GFP_KERNEL);
if (!subclks) {
pr_err(%s: could not allocate subclks\n, __func__);
- return;
+ goto err_map;
}
onecell_data = kzalloc(sizeof(struct clk_onecell_data), GFP_KERNEL);
@@ -230,30 +234,52 @@ static void __init core_pll_init(struct device_node
*np)
goto err_cell;
}
+ iounmap(base);
return;
err_cell:
kfree(onecell_data);
err_clks:
kfree(subclks);
+err_map:
+ iounmap(base);
+}
Consider devres -- is there a devres version of of_iomap()?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [1/3] powerpc/fsl-booke: Add support for T2080/T2081 SoC
On Mon, Mar 03, 2014 at 05:50:18PM +0800, Shengzhou Liu wrote:
+ corenet-cf@18000 {
+ compatible = fsl,corenet-cf;
+ reg = 0x18000 0x1000;
+ interrupts = 16 2 1 31;
+ fsl,ccf-num-csdids = 32;
+ fsl,ccf-num-snoopids = 32;
+ };
As I told Prabhakar in
https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-March/116093.html
this needs a binding and a new compatible property.
+ clockgen: global-utilities@e1000 {
+ compatible = fsl,t2080-clockgen, fsl,qoriq-clockgen-2.0;
+ reg = 0xe1000 0x1000;
+ };
See Documentation/devicetree/bindings/clock/corenet-clock.txt
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] T1040RDB: add qe node for T1040RDB dts
On Wed, 2014-03-12 at 20:56 -0500, Zhao Qiang-B45475 wrote: On Wed, 2014-03-13 at 2:46 AM, Scott wrote: -Original Message- From: Wood Scott-B07421 Sent: Thursday, March 13, 2014 2:46 AM To: Zhao Qiang-B45475 Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Xie Xiaobo-R63061 Subject: Re: [PATCH] T1040RDB: add qe node for T1040RDB dts On Wed, 2014-03-12 at 16:26 +0800, Zhao Qiang wrote: Signed-off-by: Zhao Qiang b45...@freescale.com --- arch/powerpc/boot/dts/t1040rdb.dts | 43 ++ 1 file changed, 43 insertions(+) Presumably this is on top of this patch: http://patchwork.ozlabs.org/patch/314138/ ...since there's no existing t1040 device tree support. Always mention when your patch is on top of a patch that hasn't yet been merged and isn't in the same patch set. At least some of this stuff seems like it should be in t1040si-post.dts (or a file included by it), rather than the board dts. Every board can use ucc differently, It is not correct to put this node into t1040si-post.dtsi. For example t1040qds can use ucc1 to tdm while maybe t1040rdb use ucc1 to uart. That's why I said some. :-) Anything that is specific to the board should be in the board file, but it's not clear that everything in this patch is board-specific. si/siram? Reg/ranges on the qe node? Etc. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [2/2] fsl/pci: The new pci suspend/resume implementation
Hi Scott,
I will send v2 patch to fix your comment. Thanks for your review. :)
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, March 20, 2014 5:01 AM
To: Wang Dongsheng-B40534
Cc: bhelg...@google.com; r...@rjwysocki.net; roy.z...@freescale.com;
ga...@codeaurora.org; linux-...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
Subject: Re: [2/2] fsl/pci: The new pci suspend/resume implementation
On Tue, Jan 07, 2014 at 04:04:08PM +0800, Dongsheng Wang wrote:
From: Wang Dongsheng dongsheng.w...@freescale.com
The new suspend/resume implementation, send pme turnoff message in
suspend, and send pme exit message in resume.
Add a PME handler, to response PME message interrupt.
Change platform_driver-suspend/resume to syscore-suspend/resume.
pci-driver will call back EP device, to save EP state in
pci_pm_suspend_noirq, so we need to keep the link, until
pci_pm_suspend_noirq finish.
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
Is this patch OK to go in without patch 1/2? It's not clear whether that was
deemed incorrect (as in new patch coming) or unnecessary.
Yes, I will abandon 1/2. And send this as a independent patch.
It would also be good if you submit with the explanation from
http://www.spinics.net/lists/linux-pci/msg27844.html in the commit message.
Thanks.
-static int fsl_pci_probe(struct platform_device *pdev)
+#ifdef CONFIG_PM
+static irqreturn_t fsl_pci_pme_handle(int irq, void *dev_id)
{
- int ret;
- struct device_node *node;
+ struct pci_controller *hose = dev_id;
+ struct ccsr_pci __iomem *pci = hose-private_data;
+ u32 dr;
- node = pdev-dev.of_node;
- ret = fsl_add_bridge(pdev, fsl_pci_primary == node);
+ dr = in_be32(pci-pex_pme_mes_dr);
+ if (dr)
+ out_be32(pci-pex_pme_mes_dr, dr);
+ else
+ return IRQ_NONE;
- mpc85xx_pci_err_probe(pdev);
+ return IRQ_HANDLED;
+}
Why do you put some of the HANDLED path in the if statement, and some outside?
Just do:
if (!dr)
return IRQ_NONE;
out_be32(...);
return IRQ_HANDLED;
Right. :)
+static int fsl_pci_pme_probe(struct pci_controller *hose) {
+ struct ccsr_pci __iomem *pci;
+ struct pci_dev *dev = hose-bus-self;
+ u16 pms;
+ int pme_irq;
+ int res;
+
+ /* PME Disable */
+ pci_read_config_word(dev, dev-pm_cap + PCI_PM_CTRL, pms);
+ pms = ~PCI_PM_CTRL_PME_ENABLE;
+ pci_write_config_word(dev, dev-pm_cap + PCI_PM_CTRL, pms);
+
+ pme_irq = irq_of_parse_and_map(hose-dn, 0);
+ if (!pme_irq) {
+ pr_warn(Failed to map PME interrupt.\n);
dev_err()
+
+ return -ENXIO;
+ }
+
+ res = devm_request_irq(hose-parent, pme_irq,
+ fsl_pci_pme_handle,
+ IRQF_DISABLED | IRQF_SHARED,
+ [PCI] PME, hose);
IRQF_DISABLED is a deprecated no-op.
+ if (res 0) {
+ pr_warn(Unable to requiest irq %d for PME\n, pme_irq);
dev_err() etc.
Ok, I will use it.
Regards,
-Dongsheng
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] fsl/pci: The new pci suspend/resume implementation
From: Wang Dongsheng dongsheng.w...@freescale.com
If we do nothing in suspend/resume, some platform PCIe ip-block
can't guarantee the link back to L0 state from sleep, then, when
we read the EP device will hang. Only we send pme turnoff message
in pci controller suspend, and send pme exit message in resume, the
link state will be normal.
When we send pme turnoff message in pci controller suspend, the
links will into l2/l3 ready, then, host cannot communicate with
ep device, but pci-driver will call back EP device to save them
state. So we need to change platform_driver-suspend/resume to
syscore-suspend/resume.
So the new suspend/resume implementation, send pme turnoff message
in suspend, and send pme exit message in resume. And add a PME handler,
to response PME message interrupt.
Change platform_driver-suspend/resume to syscore-suspend/resume.
pci-driver will call back EP device, to save EP state in
pci_pm_suspend_noirq, so we need to keep the link, until
pci_pm_suspend_noirq finish.
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
---
*V2*
- Abandon patch 1/2. And send this as a independent patch.
The original patch links:
patch 1/2, http://patchwork.ozlabs.org/patch/307553/ (Abandon)
patch 2/2, http://patchwork.ozlabs.org/patch/307554/
- Change pr_warn to dev_err().
- Fix code style that to deal with if statement.
diff --git a/arch/powerpc/platforms/85xx/c293pcie.c
b/arch/powerpc/platforms/85xx/c293pcie.c
index 213d5b8..84476b6 100644
--- a/arch/powerpc/platforms/85xx/c293pcie.c
+++ b/arch/powerpc/platforms/85xx/c293pcie.c
@@ -68,6 +68,7 @@ define_machine(c293_pcie) {
.init_IRQ = c293_pcie_pic_init,
#ifdef CONFIG_PCI
.pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+ .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
#endif
.get_irq= mpic_get_irq,
.restart= fsl_rstcr_restart,
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c
b/arch/powerpc/platforms/85xx/corenet_generic.c
index fbd871e..aa8b9a3 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -163,6 +163,7 @@ define_machine(corenet_generic) {
.init_IRQ = corenet_gen_pic_init,
#ifdef CONFIG_PCI
.pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+ .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
#endif
.get_irq= mpic_get_coreint_irq,
.restart= fsl_rstcr_restart,
diff --git a/arch/powerpc/platforms/85xx/ge_imp3a.c
b/arch/powerpc/platforms/85xx/ge_imp3a.c
index e6285ae..11790e0 100644
--- a/arch/powerpc/platforms/85xx/ge_imp3a.c
+++ b/arch/powerpc/platforms/85xx/ge_imp3a.c
@@ -215,6 +215,7 @@ define_machine(ge_imp3a) {
.show_cpuinfo = ge_imp3a_show_cpuinfo,
#ifdef CONFIG_PCI
.pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+ .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
#endif
.get_irq= mpic_get_irq,
.restart= fsl_rstcr_restart,
diff --git a/arch/powerpc/platforms/85xx/mpc8536_ds.c
b/arch/powerpc/platforms/85xx/mpc8536_ds.c
index 15ce4b5..a378ba3 100644
--- a/arch/powerpc/platforms/85xx/mpc8536_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc8536_ds.c
@@ -76,6 +76,7 @@ define_machine(mpc8536_ds) {
.init_IRQ = mpc8536_ds_pic_init,
#ifdef CONFIG_PCI
.pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+ .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
#endif
.get_irq= mpic_get_irq,
.restart= fsl_rstcr_restart,
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_cds.c
b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
index 7a31a0e..b0753e2 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_cds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
@@ -385,6 +385,7 @@ define_machine(mpc85xx_cds) {
#ifdef CONFIG_PCI
.restart= mpc85xx_cds_restart,
.pcibios_fixup_bus = mpc85xx_cds_fixup_bus,
+ .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
#else
.restart= fsl_rstcr_restart,
#endif
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index 9ebb91e..ffdf021 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -209,6 +209,7 @@ define_machine(mpc8544_ds) {
.init_IRQ = mpc85xx_ds_pic_init,
#ifdef CONFIG_PCI
.pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+ .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
#endif
.get_irq= mpic_get_irq,
.restart= fsl_rstcr_restart,
@@ -223,6 +224,7 @@ define_machine(mpc8572_ds) {
.init_IRQ = mpc85xx_ds_pic_init,
#ifdef CONFIG_PCI
.pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+ .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
#endif
.get_irq
Pull request: scottwood/linux.git next
The following changes since commit c7e64b9ce04aa2e3fad7396d92b5cb92056d16ac: powerpc/powernv Platform dump interface (2014-03-07 16:19:10 +1100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git next for you to fetch changes up to 48b16180d0d91324e5d2423c6d53d97bbe3dcc14: fsl/pci: The new pci suspend/resume implementation (2014-03-19 22:37:44 -0500) Luis Henriques (1): powerpc/kconfig: Remove TSI108_BRIDGE duplicates Minghuan Lian (1): powerpc/pci: Fix IMMRBAR address Prabhakar Kushwaha (1): powerpc/config: Remove unnecssary CONFIG_FSL_IFC Scott Wood (8): powerpc/booke64: Fix exception numbers powerpc/e6500: Make TLB lock recursive powerpc/booke64: Use SPRG7 for VDSO powerpc/booke64: Use SPRG_TLB_EXFRAME on bolted handlers powerpc/booke64: Remove ints from EXCEPTION_COMMON powerpc/booke64: Add crit/mc/debug support to EXCEPTION_COMMON powerpc/booke64: Critical and machine check exception support Revert powerpc/watchdog: Don't enable interrupt on PPC64 BookE Sebastian Siewior (1): powerpc: 85xx rdb: move np pointer to avoid builderror Tang Yuantian (2): powerpc/mpc85xx: Update clock nodes in device tree powerpc: T4240: Add ina220 node in dts Tiejun Chen (2): powerpc/book3e: initialize crit/mc/dbg kernel stack pointers powerpc/book3e: store crit/mc/dbg exception thread info Wang Dongsheng (2): powerpc/fsl: add PVR definition for E500MC and E5500 fsl/pci: The new pci suspend/resume implementation Zhao Qiang (2): QE: split function mpc85xx_qe_init() into two functions. Corenet: Add QE platform support for Corenet harninder rai (1): powerpc/fsl: Add/update miscellaneous missing binding .../devicetree/bindings/powerpc/fsl/l2cache.txt| 23 ++ .../devicetree/bindings/powerpc/fsl/mem-ctrlr.txt | 27 ++ Documentation/devicetree/bindings/usb/fsl-usb.txt | 4 +- arch/powerpc/boot/dts/fsl/b4420si-post.dtsi| 36 ++ arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi | 2 + arch/powerpc/boot/dts/fsl/b4860si-post.dtsi| 36 ++ arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi | 4 + arch/powerpc/boot/dts/fsl/p2041si-post.dtsi| 60 +++ arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi | 4 + arch/powerpc/boot/dts/fsl/p3041si-post.dtsi| 61 +++ arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi | 4 + arch/powerpc/boot/dts/fsl/p4080si-post.dtsi| 113 ++ arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi | 8 + arch/powerpc/boot/dts/fsl/p5020si-post.dtsi| 43 ++ arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi | 2 + arch/powerpc/boot/dts/fsl/p5040si-post.dtsi| 61 +++ arch/powerpc/boot/dts/fsl/p5040si-pre.dtsi | 4 + arch/powerpc/boot/dts/fsl/t4240si-post.dtsi| 86 arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi | 12 + arch/powerpc/boot/dts/t4240qds.dts | 42 ++ arch/powerpc/configs/corenet64_smp_defconfig | 1 - arch/powerpc/configs/mpc85xx_defconfig | 1 - arch/powerpc/configs/mpc85xx_smp_defconfig | 1 - arch/powerpc/include/asm/exception-64e.h | 15 +- arch/powerpc/include/asm/kvm_booke_hv_asm.h| 17 +- arch/powerpc/include/asm/mmu-book3e.h | 9 +- arch/powerpc/include/asm/paca.h| 9 +- arch/powerpc/include/asm/reg.h | 15 +- arch/powerpc/kernel/asm-offsets.c | 2 +- arch/powerpc/kernel/exceptions-64e.S | 435 - arch/powerpc/kernel/setup_64.c | 20 +- arch/powerpc/kernel/vdso.c | 8 +- arch/powerpc/kernel/vdso32/getcpu.S| 2 +- arch/powerpc/kernel/vdso64/getcpu.S| 2 +- arch/powerpc/kvm/book3s_hv_rmhandlers.S| 4 +- arch/powerpc/kvm/book3s_interrupts.S | 4 +- arch/powerpc/kvm/bookehv_interrupts.S | 21 +- arch/powerpc/mm/tlb_low_64e.S | 63 +-- arch/powerpc/mm/tlb_nohash.c | 11 + arch/powerpc/platforms/85xx/c293pcie.c | 1 + arch/powerpc/platforms/85xx/common.c | 6 + arch/powerpc/platforms/85xx/corenet_generic.c | 17 + arch/powerpc/platforms/85xx/ge_imp3a.c | 1 + arch/powerpc/platforms/85xx/mpc8536_ds.c | 1 + arch/powerpc/platforms/85xx/mpc85xx.h | 2 + arch/powerpc/platforms/85xx/mpc85xx_cds.c | 1 + arch/powerpc/platforms/85xx/mpc85xx_ds.c | 3 + arch/powerpc/platforms/85xx/mpc85xx_mds.c | 4 + arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 16 +- arch/powerpc/platforms/85xx/p1010rdb.c | 1 + arch/powerpc/platforms/85xx/p1022_ds.c | 1 +
Re: 3.16.6 build error: swsusp_booke.S:85: Error: invalid sprg number
On Wed, 2014-03-19 at 17:58 -0500, John Donnelly wrote: Platform: Freescale p4080--e500mc , Suggestions welcome . /bin/sh arch/powerpc/kernel/systbl_chk.sh arch/powerpc/kernel/systbl_chk.i make -f scripts/Makefile.build obj=arch/powerpc/kernel/vdso32 gcc -mbig-endian -m32 -Wp,-MD,arch/powerpc/kernel/.swsusp_booke.o.d -nostdinc -isystem /usr/lib/gcc/ppc64-redhat-linux/4.8.2/include -I/root/linux-3.13.6/arch/powerpc/include -Iarch/powerpc/include/generated -Iinclude -I/root/linux-3.13.6/arch/powerpc/include/uapi -Iarch/powerpc/include/generated/uapi -I/root/linux-3.13.6/include/uapi -Iinclude/generated/uapi -include /root/linux-3.13.6/include/linux/kconfig.h -D__KERNEL__ -Iarch/powerpc -D__ASSEMBLY__ -Iarch/powerpc -gdwarf-2 -c -o arch/powerpc/kernel/swsusp_booke.o arch/powerpc/kernel/swsusp_booke.S arch/powerpc/kernel/swsusp_booke.S: Assembler messages: arch/powerpc/kernel/swsusp_booke.S:85: Error: invalid sprg number arch/powerpc/kernel/swsusp_booke.S:87: Error: invalid sprg number You need commit b58a7bd6df7b61446b833a7c72f8a1f11066e0b0. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Tasks stuck in futex code (in 3.14-rc6)
Joy,.. let me look at that with ppc in mind. OK; so while pretty much all the comments from that patch are utter nonsense (what was I thinking), I cannot actually find a real bug. But could you try the below which replaces a control dependency with a full barrier. The control flow is plenty convoluted that I think the control barrier isn't actually valid anymore and that might indeed explain the fail. Unfortunately the patch didnt help. Still seeing tasks stuck # ps -Ao pid,tt,user,fname,tmout,f,wchan | grep futex 14680 pts/0root java - 0 futex_wait_queue_me 14797 pts/0root java - 0 futex_wait_queue_me # : /var/log/messages # echo t /proc/sysrq-trigger # grep futex_wait_queue_me /var/log/messages | wc -l 334 # [ 6904.211478] Call Trace: [ 6904.211481] [c00fa1f1b4d0] [0020] 0x20 (unreliable) [ 6904.211486] [c00fa1f1b6a0] [c0015208] .__switch_to+0x1e8/0x330 [ 6904.211491] [c00fa1f1b750] [c0702f00] .__schedule+0x360/0x8b0 [ 6904.211495] [c00fa1f1b9d0] [c0147348] .futex_wait_queue_me+0xf8/0x1a0 [ 6904.211500] [c00fa1f1ba60] [c01486dc] .futex_wait+0x17c/0x2a0 [ 6904.211505] [c00fa1f1bc10] [c014a614] .do_futex+0x254/0xd80 [ 6904.211510] [c00fa1f1bd60] [c014b25c] .SyS_futex+0x11c/0x1d0 [ 6904.238874] [c00fa1f1be30] [c000a0fc] syscall_exit+0x0/0x7c [ 6904.238879] javaS 3fff825f6044 0 14682 14076 0x0080 Is there any other information that I provide that can help? -- Thanks and Regards Srikar Dronamraju ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Tasks stuck in futex code (in 3.14-rc6)
On Thu, 2014-03-20 at 11:03 +0530, Srikar Dronamraju wrote: Joy,.. let me look at that with ppc in mind. OK; so while pretty much all the comments from that patch are utter nonsense (what was I thinking), I cannot actually find a real bug. But could you try the below which replaces a control dependency with a full barrier. The control flow is plenty convoluted that I think the control barrier isn't actually valid anymore and that might indeed explain the fail. Unfortunately the patch didnt help. Still seeing tasks stuck # ps -Ao pid,tt,user,fname,tmout,f,wchan | grep futex 14680 pts/0root java - 0 futex_wait_queue_me 14797 pts/0root java - 0 futex_wait_queue_me # : /var/log/messages # echo t /proc/sysrq-trigger # grep futex_wait_queue_me /var/log/messages | wc -l 334 # [ 6904.211478] Call Trace: [ 6904.211481] [c00fa1f1b4d0] [0020] 0x20 (unreliable) [ 6904.211486] [c00fa1f1b6a0] [c0015208] .__switch_to+0x1e8/0x330 [ 6904.211491] [c00fa1f1b750] [c0702f00] .__schedule+0x360/0x8b0 [ 6904.211495] [c00fa1f1b9d0] [c0147348] .futex_wait_queue_me+0xf8/0x1a0 [ 6904.211500] [c00fa1f1ba60] [c01486dc] .futex_wait+0x17c/0x2a0 [ 6904.211505] [c00fa1f1bc10] [c014a614] .do_futex+0x254/0xd80 [ 6904.211510] [c00fa1f1bd60] [c014b25c] .SyS_futex+0x11c/0x1d0 [ 6904.238874] [c00fa1f1be30] [c000a0fc] syscall_exit+0x0/0x7c [ 6904.238879] javaS 3fff825f6044 0 14682 14076 0x0080 Is there any other information that I provide that can help? This problem suggests that we missed a wakeup for a task that was adding itself to the queue in a wait path. And the only place that can happen is with the hb spinlock check for any pending waiters. Just in case we missed some assumption about checking the hash bucket spinlock as a way of detecting any waiters (powerpc?), could you revert this commit and try the original atomic operations variant: https://lkml.org/lkml/2013/12/19/630 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
