* RE: PCIe Access - achieve bursts without DMA
From: David Laight @ 2014-01-30 14:19 UTC (permalink / raw)
To: 'Moese, Michael', linuxppc-dev@lists.ozlabs.org
In-Reply-To: <2DF74D4E746FF14C8697D5041AAE72D56A2B1420@MEN-EX2.intra.men.de>
>From Moese, Michael
> Hello PPC-developers,
> I'm currently trying to benchmark access speeds to our PCIe-connected IP-=
cores
> located inside our FPGA. On x86-based systems I was able to achieve burst=
s for
> both read and write access. On PPC32, using an e500v2, I had no success a=
t all
> so far.
I'm not sure that you can.
I had to write a simple driver for the PCIe CSB bridge dma on a 83xx ppc.
I think that might be the one in the e500v2.
I don't know how fast 'normal' PCIe slaves are, but we were accessing
an Altera fpga and the latency is less than pedestrian.
I think an ISA bus can run faster!
With moderate length transfers, the throughput was more than adequate.
David
^ permalink raw reply
* [PATCH v2] kexec/ppc64 fix device tree endianess issues for memory attributes
From: Laurent Dufour @ 2014-01-30 15:06 UTC (permalink / raw)
To: Simon Horman, kexec; +Cc: linuxppc-dev, Anton Blanchard, Mahesh Salgaonkar
All the attributes exposed in the device tree are in Big Endian format.
This patch add the byte swap operation for some entries which were not yet
processed, including those fixed by the following kernel's patch :
https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-January/114720.html
To work on PPC64 Little Endian mode, kexec now requires that the kernel's
patch mentioned above is applied on the kexecing kernel.
Tested on ppc64 LPAR (kexec/dump) and ppc64le in a Qemu/KVM guest (kexec)
Changes from v1 :
* add processing of the following entries :
- ibm,dynamic-reconfiguration-memory
- chosen/linux,kernel-end
- chosen/linux,crashkernel-base & size
- chosen/linux,memory-limit
- chosen/linux,htab-base & size
- linux,tce-base & size
- memory@/reg
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
---
kexec/arch/ppc64/crashdump-ppc64.c | 9 ++++---
kexec/arch/ppc64/kexec-ppc64.c | 44 +++++++++++++++++++++++++++---------
kexec/fs2dt.c | 19 ++++++++--------
3 files changed, 48 insertions(+), 24 deletions(-)
diff --git a/kexec/arch/ppc64/crashdump-ppc64.c b/kexec/arch/ppc64/crashdump-ppc64.c
index e31dd6d..c0d575d 100644
--- a/kexec/arch/ppc64/crashdump-ppc64.c
+++ b/kexec/arch/ppc64/crashdump-ppc64.c
@@ -146,12 +146,12 @@ static int get_dyn_reconf_crash_memory_ranges(void)
return -1;
}
- start = ((uint64_t *)buf)[DRCONF_ADDR];
+ start = be64_to_cpu(((uint64_t *)buf)[DRCONF_ADDR]);
end = start + lmb_size;
if (start == 0 && end >= (BACKUP_SRC_END + 1))
start = BACKUP_SRC_END + 1;
- flags = (*((uint32_t *)&buf[DRCONF_FLAGS]));
+ flags = be32_to_cpu((*((uint32_t *)&buf[DRCONF_FLAGS])));
/* skip this block if the reserved bit is set in flags (0x80)
or if the block is not assigned to this partition (0x8) */
if ((flags & 0x80) || !(flags & 0x8))
@@ -252,8 +252,9 @@ static int get_crash_memory_ranges(struct memory_range **range, int *ranges)
goto err;
}
- start = ((unsigned long long *)buf)[0];
- end = start + ((unsigned long long *)buf)[1];
+ start = be64_to_cpu(((unsigned long long *)buf)[0]);
+ end = start +
+ be64_to_cpu(((unsigned long long *)buf)[1]);
if (start == 0 && end >= (BACKUP_SRC_END + 1))
start = BACKUP_SRC_END + 1;
diff --git a/kexec/arch/ppc64/kexec-ppc64.c b/kexec/arch/ppc64/kexec-ppc64.c
index af9112b..49b291d 100644
--- a/kexec/arch/ppc64/kexec-ppc64.c
+++ b/kexec/arch/ppc64/kexec-ppc64.c
@@ -167,7 +167,7 @@ static int get_dyn_reconf_base_ranges(void)
* lmb_size, num_of_lmbs(global variables) are
* initialized once here.
*/
- lmb_size = ((uint64_t *)buf)[0];
+ lmb_size = be64_to_cpu(((uint64_t *)buf)[0]);
fclose(file);
strcpy(fname, "/proc/device-tree/");
@@ -183,7 +183,7 @@ static int get_dyn_reconf_base_ranges(void)
fclose(file);
return -1;
}
- num_of_lmbs = ((unsigned int *)buf)[0];
+ num_of_lmbs = be32_to_cpu(((unsigned int *)buf)[0]);
for (i = 0; i < num_of_lmbs; i++) {
if ((n = fread(buf, 1, 24, file)) < 0) {
@@ -194,7 +194,7 @@ static int get_dyn_reconf_base_ranges(void)
if (nr_memory_ranges >= max_memory_ranges)
return -1;
- start = ((uint64_t *)buf)[0];
+ start = be64_to_cpu(((uint64_t *)buf)[0]);
end = start + lmb_size;
add_base_memory_range(start, end);
}
@@ -278,8 +278,8 @@ static int get_base_ranges(void)
if (realloc_memory_ranges() < 0)
break;
}
- start = ((uint64_t *)buf)[0];
- end = start + ((uint64_t *)buf)[1];
+ start = be64_to_cpu(((uint64_t *)buf)[0]);
+ end = start + be64_to_cpu(((uint64_t *)buf)[1]);
add_base_memory_range(start, end);
fclose(file);
}
@@ -363,6 +363,7 @@ static int get_devtree_details(unsigned long kexec_flags)
goto error_openfile;
}
fclose(file);
+ kernel_end = be64_to_cpu(kernel_end);
/* Add kernel memory to exclude_range */
exclude_range[i].start = 0x0UL;
@@ -386,6 +387,7 @@ static int get_devtree_details(unsigned long kexec_flags)
goto error_openfile;
}
fclose(file);
+ crash_base = be64_to_cpu(crash_base);
memset(fname, 0, sizeof(fname));
strcpy(fname, device_tree);
@@ -400,6 +402,8 @@ static int get_devtree_details(unsigned long kexec_flags)
perror(fname);
goto error_openfile;
}
+ fclose(file);
+ crash_size = be64_to_cpu(crash_size);
if (crash_base > mem_min)
mem_min = crash_base;
@@ -430,10 +434,14 @@ static int get_devtree_details(unsigned long kexec_flags)
* fall through. On older kernel this file
* is not present.
*/
- } else if (fread(&memory_limit, sizeof(uint64_t), 1,
- file) != 1) {
- perror(fname);
- goto error_openfile;
+ } else {
+ if (fread(&memory_limit, sizeof(uint64_t), 1,
+ file) != 1) {
+ perror(fname);
+ goto error_openfile;
+ }
+ fclose(file);
+ memory_limit = be64_to_cpu(memory_limit);
}
memset(fname, 0, sizeof(fname));
@@ -454,6 +462,9 @@ static int get_devtree_details(unsigned long kexec_flags)
perror(fname);
goto error_openfile;
}
+ fclose(file);
+ htab_base = be64_to_cpu(htab_base);
+
memset(fname, 0, sizeof(fname));
strcpy(fname, device_tree);
strcat(fname, dentry->d_name);
@@ -466,6 +477,9 @@ static int get_devtree_details(unsigned long kexec_flags)
perror(fname);
goto error_openfile;
}
+ fclose(file);
+ htab_size = be64_to_cpu(htab_size);
+
/* Add htab address to exclude_range - NON-LPAR only */
exclude_range[i].start = htab_base;
exclude_range[i].end = htab_base + htab_size;
@@ -492,6 +506,7 @@ static int get_devtree_details(unsigned long kexec_flags)
perror(fname);
goto error_openfile;
}
+ initrd_start = be64_to_cpu(initrd_start);
fclose(file);
memset(fname, 0, sizeof(fname));
@@ -511,6 +526,7 @@ static int get_devtree_details(unsigned long kexec_flags)
perror(fname);
goto error_openfile;
}
+ initrd_end = be64_to_cpu(initrd_end);
fclose(file);
/* Add initrd address to exclude_range */
@@ -532,6 +548,7 @@ static int get_devtree_details(unsigned long kexec_flags)
perror(fname);
goto error_openfile;
}
+ fclose(file);
rtas_base = be32_to_cpu(rtas_base);
memset(fname, 0, sizeof(fname));
strcpy(fname, device_tree);
@@ -545,6 +562,7 @@ static int get_devtree_details(unsigned long kexec_flags)
perror(fname);
goto error_openfile;
}
+ fclose(file);
closedir(cdir);
rtas_size = be32_to_cpu(rtas_size);
/* Add rtas to exclude_range */
@@ -568,8 +586,8 @@ static int get_devtree_details(unsigned long kexec_flags)
perror(fname);
goto error_openfile;
}
- rmo_base = ((uint64_t *)buf)[0];
- rmo_top = rmo_base + ((uint64_t *)buf)[1];
+ rmo_base = be64_to_cpu(((uint64_t *)buf)[0]);
+ rmo_top = rmo_base + be64_to_cpu(((uint64_t *)buf)[1]);
if (rmo_top > 0x30000000UL)
rmo_top = 0x30000000UL;
@@ -593,6 +611,8 @@ static int get_devtree_details(unsigned long kexec_flags)
perror(fname);
goto error_openfile;
}
+ fclose(file);
+ tce_base = be64_to_cpu(tce_base);
memset(fname, 0, sizeof(fname));
strcpy(fname, device_tree);
strcat(fname, dentry->d_name);
@@ -605,6 +625,8 @@ static int get_devtree_details(unsigned long kexec_flags)
perror(fname);
goto error_openfile;
}
+ fclose(file);
+ tce_size = be32_to_cpu(tce_size);
/* Add tce to exclude_range - NON-LPAR only */
exclude_range[i].start = tce_base;
exclude_range[i].end = tce_base + tce_size;
diff --git a/kexec/fs2dt.c b/kexec/fs2dt.c
index 7202dc1..73c1fb9 100644
--- a/kexec/fs2dt.c
+++ b/kexec/fs2dt.c
@@ -197,7 +197,7 @@ static void add_dyn_reconf_usable_mem_property__(int fd)
die("unrecoverable error: error reading \"%s\": %s\n",
pathname, strerror(errno));
- base = (uint64_t) buf[0];
+ base = be64_to_cpu((uint64_t) buf[0]);
end = base + lmb_size;
if (~0ULL - base < end)
die("unrecoverable error: mem property overflow\n");
@@ -229,8 +229,8 @@ static void add_dyn_reconf_usable_mem_property__(int fd)
" ranges.\n",
ranges_size*8);
}
- ranges[rlen++] = loc_base;
- ranges[rlen++] = loc_end - loc_base;
+ ranges[rlen++] = cpu_to_be64(loc_base);
+ ranges[rlen++] = cpu_to_be64(loc_end - loc_base);
rngs_cnt++;
}
}
@@ -255,7 +255,7 @@ static void add_dyn_reconf_usable_mem_property__(int fd)
}
} else {
/* Store the count of (base, size) duple */
- ranges[tmp_indx] = rngs_cnt;
+ ranges[tmp_indx] = cpu_to_be64((uint64_t) rngs_cnt);
}
}
@@ -309,10 +309,11 @@ static void add_usable_mem_property(int fd, size_t len)
die("unrecoverable error: error reading \"%s\": %s\n",
pathname, strerror(errno));
- if (~0ULL - buf[0] < buf[1])
- die("unrecoverable error: mem property overflow\n");
base = be64_to_cpu(buf[0]);
- end = base + be64_to_cpu(buf[1]);
+ end = be64_to_cpu(buf[1]);
+ if (~0ULL - base < end)
+ die("unrecoverable error: mem property overflow\n");
+ end += base;
ranges = malloc(ranges_size * sizeof(*ranges));
if (!ranges)
@@ -342,8 +343,8 @@ static void add_usable_mem_property(int fd, size_t len)
"%d bytes for ranges.\n",
ranges_size*sizeof(*ranges));
}
- ranges[rlen++] = loc_base;
- ranges[rlen++] = loc_end - loc_base;
+ ranges[rlen++] = cpu_to_be64(loc_base);
+ ranges[rlen++] = cpu_to_be64(loc_end - loc_base);
}
}
^ permalink raw reply related
* Re: [PATCH v2 6/6] cpu/idle.c: move to sched/idle.c
From: Peter Zijlstra @ 2014-01-30 15:25 UTC (permalink / raw)
To: Nicolas Pitre
Cc: linaro-kernel, Russell King, linux-sh, linux-pm, Daniel Lezcano,
Rafael J. Wysocki, linux-kernel, Paul Mundt, Preeti U Murthy,
Thomas Gleixner, linuxppc-dev, Ingo Molnar, linux-arm-kernel
In-Reply-To: <1391017513-12995-7-git-send-email-nicolas.pitre@linaro.org>
On Wed, Jan 29, 2014 at 12:45:13PM -0500, Nicolas Pitre wrote:
> Integration of cpuidle with the scheduler requires that the idle loop be
> closely integrated with the scheduler proper. Moving cpu/idle.c into the
> sched directory will allow for a smoother integration, and eliminate a
> subdirectory which contained only one source file.
>
> Signed-off-by: Nicolas Pitre <nico@linaro.org>
> ---
> kernel/Makefile | 1 -
> kernel/cpu/Makefile | 1 -
> kernel/sched/Makefile | 2 +-
> kernel/{cpu => sched}/idle.c | 0
> 4 files changed, 1 insertion(+), 3 deletions(-)
> delete mode 100644 kernel/cpu/Makefile
> rename kernel/{cpu => sched}/idle.c (100%)
> --- a/kernel/sched/Makefile
> +++ b/kernel/sched/Makefile
> @@ -11,7 +11,7 @@ ifneq ($(CONFIG_SCHED_OMIT_FRAME_POINTER),y)
> CFLAGS_core.o := $(PROFILING) -fno-omit-frame-pointer
> endif
>
> -obj-y += core.o proc.o clock.o cputime.o idle_task.o fair.o rt.o stop_task.o
> +obj-y += core.o proc.o clock.o cputime.o idle_task.o idle.o fair.o rt.o stop_task.o
> obj-y += wait.o completion.o
> obj-$(CONFIG_SMP) += cpupri.o
> obj-$(CONFIG_SCHED_AUTOGROUP) += auto_group.o
> diff --git a/kernel/cpu/idle.c b/kernel/sched/idle.c
> similarity index 100%
> rename from kernel/cpu/idle.c
> rename to kernel/sched/idle.c
This is not a valid patch for PATCH(1). Please try again.
^ permalink raw reply
* [RESEND PATCH] powerpc/relocate fix relocate processing in LE mode
From: Laurent Dufour @ 2014-01-30 15:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, linuxppc-dev
Relocation's code is not working in little endian mode because the r_info
field, which is a 64 bits value, should be read from the right offset.
The current code is optimized to read the r_info field as a 32 bits value
starting at the middle of the double word (offset 12). When running in LE
mode, the read value is not correct since only the MSB is read.
This patch removes this optimization which consist to deal with a 32 bits
value instead of a 64 bits one. This way it works in big and little endian
mode.
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
---
arch/powerpc/kernel/reloc_64.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/reloc_64.S b/arch/powerpc/kernel/reloc_64.S
index b47a0e1..1482327 100644
--- a/arch/powerpc/kernel/reloc_64.S
+++ b/arch/powerpc/kernel/reloc_64.S
@@ -69,8 +69,8 @@ _GLOBAL(relocate)
* R_PPC64_RELATIVE ones.
*/
mtctr r8
-5: lwz r0,12(9) /* ELF64_R_TYPE(reloc->r_info) */
- cmpwi r0,R_PPC64_RELATIVE
+5: ld r0,8(9) /* ELF64_R_TYPE(reloc->r_info) */
+ cmpdi r0,R_PPC64_RELATIVE
bne 6f
ld r6,0(r9) /* reloc->r_offset */
ld r0,16(r9) /* reloc->r_addend */
^ permalink raw reply related
* Re: [PATCH v2 6/6] cpu/idle.c: move to sched/idle.c
From: Nicolas Pitre @ 2014-01-30 16:03 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linaro-kernel, Russell King, linux-sh, linux-pm, Daniel Lezcano,
Rafael J. Wysocki, linux-kernel, Paul Mundt, Preeti U Murthy,
Thomas Gleixner, linuxppc-dev, Ingo Molnar, linux-arm-kernel
In-Reply-To: <20140130152500.GB5002@laptop.programming.kicks-ass.net>
On Thu, 30 Jan 2014, Peter Zijlstra wrote:
> On Wed, Jan 29, 2014 at 12:45:13PM -0500, Nicolas Pitre wrote:
> > Integration of cpuidle with the scheduler requires that the idle loop be
> > closely integrated with the scheduler proper. Moving cpu/idle.c into the
> > sched directory will allow for a smoother integration, and eliminate a
> > subdirectory which contained only one source file.
> >
> > Signed-off-by: Nicolas Pitre <nico@linaro.org>
> > ---
> > kernel/Makefile | 1 -
> > kernel/cpu/Makefile | 1 -
> > kernel/sched/Makefile | 2 +-
> > kernel/{cpu => sched}/idle.c | 0
> > 4 files changed, 1 insertion(+), 3 deletions(-)
> > delete mode 100644 kernel/cpu/Makefile
> > rename kernel/{cpu => sched}/idle.c (100%)
>
> > --- a/kernel/sched/Makefile
> > +++ b/kernel/sched/Makefile
> > @@ -11,7 +11,7 @@ ifneq ($(CONFIG_SCHED_OMIT_FRAME_POINTER),y)
> > CFLAGS_core.o := $(PROFILING) -fno-omit-frame-pointer
> > endif
> >
> > -obj-y += core.o proc.o clock.o cputime.o idle_task.o fair.o rt.o stop_task.o
> > +obj-y += core.o proc.o clock.o cputime.o idle_task.o idle.o fair.o rt.o stop_task.o
> > obj-y += wait.o completion.o
> > obj-$(CONFIG_SMP) += cpupri.o
> > obj-$(CONFIG_SCHED_AUTOGROUP) += auto_group.o
> > diff --git a/kernel/cpu/idle.c b/kernel/sched/idle.c
> > similarity index 100%
> > rename from kernel/cpu/idle.c
> > rename to kernel/sched/idle.c
>
> This is not a valid patch for PATCH(1). Please try again.
Don't you use git? ;-)
Here's a plain patch:
----- >8
>From 1bf40eb80a44633094e94986a74bd5ffa222f9d4 Mon Sep 17 00:00:00 2001
From: Nicolas Pitre <nicolas.pitre@linaro.org>
Date: Sun, 26 Jan 2014 23:42:01 -0500
Subject: [PATCH] cpu/idle.c: move to sched/idle.c
Integration of cpuidle with the scheduler requires that the idle loop be
closely integrated with the scheduler proper. Moving cpu/idle.c into the
sched directory will allow for a smoother integration, and eliminate a
subdirectory which contained only one source file.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
---
kernel/Makefile | 1 -
kernel/cpu/Makefile | 1 -
kernel/cpu/idle.c | 144 --------------------------------------------------
kernel/sched/Makefile | 2 +-
kernel/sched/idle.c | 144 ++++++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 145 insertions(+), 147 deletions(-)
delete mode 100644 kernel/cpu/Makefile
delete mode 100644 kernel/cpu/idle.c
create mode 100644 kernel/sched/idle.c
diff --git a/kernel/Makefile b/kernel/Makefile
index bc010ee272..6f1c7e5cfc 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -22,7 +22,6 @@ obj-y += sched/
obj-y += locking/
obj-y += power/
obj-y += printk/
-obj-y += cpu/
obj-y += irq/
obj-y += rcu/
diff --git a/kernel/cpu/Makefile b/kernel/cpu/Makefile
deleted file mode 100644
index 59ab052ef7..0000000000
--- a/kernel/cpu/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-obj-y = idle.o
diff --git a/kernel/cpu/idle.c b/kernel/cpu/idle.c
deleted file mode 100644
index 14ca43430a..0000000000
--- a/kernel/cpu/idle.c
+++ /dev/null
@@ -1,144 +0,0 @@
-/*
- * Generic entry point for the idle threads
- */
-#include <linux/sched.h>
-#include <linux/cpu.h>
-#include <linux/cpuidle.h>
-#include <linux/tick.h>
-#include <linux/mm.h>
-#include <linux/stackprotector.h>
-
-#include <asm/tlb.h>
-
-#include <trace/events/power.h>
-
-static int __read_mostly cpu_idle_force_poll;
-
-void cpu_idle_poll_ctrl(bool enable)
-{
- if (enable) {
- cpu_idle_force_poll++;
- } else {
- cpu_idle_force_poll--;
- WARN_ON_ONCE(cpu_idle_force_poll < 0);
- }
-}
-
-#ifdef CONFIG_GENERIC_IDLE_POLL_SETUP
-static int __init cpu_idle_poll_setup(char *__unused)
-{
- cpu_idle_force_poll = 1;
- return 1;
-}
-__setup("nohlt", cpu_idle_poll_setup);
-
-static int __init cpu_idle_nopoll_setup(char *__unused)
-{
- cpu_idle_force_poll = 0;
- return 1;
-}
-__setup("hlt", cpu_idle_nopoll_setup);
-#endif
-
-static inline int cpu_idle_poll(void)
-{
- rcu_idle_enter();
- trace_cpu_idle_rcuidle(0, smp_processor_id());
- local_irq_enable();
- while (!tif_need_resched())
- cpu_relax();
- trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, smp_processor_id());
- rcu_idle_exit();
- return 1;
-}
-
-/* Weak implementations for optional arch specific functions */
-void __weak arch_cpu_idle_prepare(void) { }
-void __weak arch_cpu_idle_enter(void) { }
-void __weak arch_cpu_idle_exit(void) { }
-void __weak arch_cpu_idle_dead(void) { }
-void __weak arch_cpu_idle(void)
-{
- cpu_idle_force_poll = 1;
- local_irq_enable();
-}
-
-/*
- * Generic idle loop implementation
- */
-static void cpu_idle_loop(void)
-{
- while (1) {
- tick_nohz_idle_enter();
-
- while (!need_resched()) {
- check_pgt_cache();
- rmb();
-
- if (cpu_is_offline(smp_processor_id()))
- arch_cpu_idle_dead();
-
- local_irq_disable();
- arch_cpu_idle_enter();
-
- /*
- * In poll mode we reenable interrupts and spin.
- *
- * Also if we detected in the wakeup from idle
- * path that the tick broadcast device expired
- * for us, we don't want to go deep idle as we
- * know that the IPI is going to arrive right
- * away
- */
- if (cpu_idle_force_poll || tick_check_broadcast_expired()) {
- cpu_idle_poll();
- } else {
- if (!current_clr_polling_and_test()) {
- stop_critical_timings();
- rcu_idle_enter();
- if (cpuidle_idle_call())
- arch_cpu_idle();
- if (WARN_ON_ONCE(irqs_disabled()))
- local_irq_enable();
- rcu_idle_exit();
- start_critical_timings();
- } else {
- local_irq_enable();
- }
- __current_set_polling();
- }
- arch_cpu_idle_exit();
- /*
- * We need to test and propagate the TIF_NEED_RESCHED
- * bit here because we might not have send the
- * reschedule IPI to idle tasks.
- */
- if (tif_need_resched())
- set_preempt_need_resched();
- }
- tick_nohz_idle_exit();
- schedule_preempt_disabled();
- }
-}
-
-void cpu_startup_entry(enum cpuhp_state state)
-{
- /*
- * This #ifdef needs to die, but it's too late in the cycle to
- * make this generic (arm and sh have never invoked the canary
- * init for the non boot cpus!). Will be fixed in 3.11
- */
-#ifdef CONFIG_X86
- /*
- * If we're the non-boot CPU, nothing set the stack canary up
- * for us. The boot CPU already has it initialized but no harm
- * in doing it again. This is a good place for updating it, as
- * we wont ever return from this function (so the invalid
- * canaries already on the stack wont ever trigger).
- */
- boot_init_stack_canary();
-#endif
- __current_set_polling();
- arch_cpu_idle_prepare();
- cpu_idle_loop();
-}
diff --git a/kernel/sched/Makefile b/kernel/sched/Makefile
index 7b621409cf..ac3e0ea68f 100644
--- a/kernel/sched/Makefile
+++ b/kernel/sched/Makefile
@@ -11,7 +11,7 @@ ifneq ($(CONFIG_SCHED_OMIT_FRAME_POINTER),y)
CFLAGS_core.o := $(PROFILING) -fno-omit-frame-pointer
endif
-obj-y += core.o proc.o clock.o cputime.o idle_task.o fair.o rt.o stop_task.o
+obj-y += core.o proc.o clock.o cputime.o idle_task.o idle.o fair.o rt.o stop_task.o
obj-y += wait.o completion.o
obj-$(CONFIG_SMP) += cpupri.o
obj-$(CONFIG_SCHED_AUTOGROUP) += auto_group.o
diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
new file mode 100644
index 0000000000..14ca43430a
--- /dev/null
+++ b/kernel/sched/idle.c
@@ -0,0 +1,144 @@
+/*
+ * Generic entry point for the idle threads
+ */
+#include <linux/sched.h>
+#include <linux/cpu.h>
+#include <linux/cpuidle.h>
+#include <linux/tick.h>
+#include <linux/mm.h>
+#include <linux/stackprotector.h>
+
+#include <asm/tlb.h>
+
+#include <trace/events/power.h>
+
+static int __read_mostly cpu_idle_force_poll;
+
+void cpu_idle_poll_ctrl(bool enable)
+{
+ if (enable) {
+ cpu_idle_force_poll++;
+ } else {
+ cpu_idle_force_poll--;
+ WARN_ON_ONCE(cpu_idle_force_poll < 0);
+ }
+}
+
+#ifdef CONFIG_GENERIC_IDLE_POLL_SETUP
+static int __init cpu_idle_poll_setup(char *__unused)
+{
+ cpu_idle_force_poll = 1;
+ return 1;
+}
+__setup("nohlt", cpu_idle_poll_setup);
+
+static int __init cpu_idle_nopoll_setup(char *__unused)
+{
+ cpu_idle_force_poll = 0;
+ return 1;
+}
+__setup("hlt", cpu_idle_nopoll_setup);
+#endif
+
+static inline int cpu_idle_poll(void)
+{
+ rcu_idle_enter();
+ trace_cpu_idle_rcuidle(0, smp_processor_id());
+ local_irq_enable();
+ while (!tif_need_resched())
+ cpu_relax();
+ trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, smp_processor_id());
+ rcu_idle_exit();
+ return 1;
+}
+
+/* Weak implementations for optional arch specific functions */
+void __weak arch_cpu_idle_prepare(void) { }
+void __weak arch_cpu_idle_enter(void) { }
+void __weak arch_cpu_idle_exit(void) { }
+void __weak arch_cpu_idle_dead(void) { }
+void __weak arch_cpu_idle(void)
+{
+ cpu_idle_force_poll = 1;
+ local_irq_enable();
+}
+
+/*
+ * Generic idle loop implementation
+ */
+static void cpu_idle_loop(void)
+{
+ while (1) {
+ tick_nohz_idle_enter();
+
+ while (!need_resched()) {
+ check_pgt_cache();
+ rmb();
+
+ if (cpu_is_offline(smp_processor_id()))
+ arch_cpu_idle_dead();
+
+ local_irq_disable();
+ arch_cpu_idle_enter();
+
+ /*
+ * In poll mode we reenable interrupts and spin.
+ *
+ * Also if we detected in the wakeup from idle
+ * path that the tick broadcast device expired
+ * for us, we don't want to go deep idle as we
+ * know that the IPI is going to arrive right
+ * away
+ */
+ if (cpu_idle_force_poll || tick_check_broadcast_expired()) {
+ cpu_idle_poll();
+ } else {
+ if (!current_clr_polling_and_test()) {
+ stop_critical_timings();
+ rcu_idle_enter();
+ if (cpuidle_idle_call())
+ arch_cpu_idle();
+ if (WARN_ON_ONCE(irqs_disabled()))
+ local_irq_enable();
+ rcu_idle_exit();
+ start_critical_timings();
+ } else {
+ local_irq_enable();
+ }
+ __current_set_polling();
+ }
+ arch_cpu_idle_exit();
+ /*
+ * We need to test and propagate the TIF_NEED_RESCHED
+ * bit here because we might not have send the
+ * reschedule IPI to idle tasks.
+ */
+ if (tif_need_resched())
+ set_preempt_need_resched();
+ }
+ tick_nohz_idle_exit();
+ schedule_preempt_disabled();
+ }
+}
+
+void cpu_startup_entry(enum cpuhp_state state)
+{
+ /*
+ * This #ifdef needs to die, but it's too late in the cycle to
+ * make this generic (arm and sh have never invoked the canary
+ * init for the non boot cpus!). Will be fixed in 3.11
+ */
+#ifdef CONFIG_X86
+ /*
+ * If we're the non-boot CPU, nothing set the stack canary up
+ * for us. The boot CPU already has it initialized but no harm
+ * in doing it again. This is a good place for updating it, as
+ * we wont ever return from this function (so the invalid
+ * canaries already on the stack wont ever trigger).
+ */
+ boot_init_stack_canary();
+#endif
+ __current_set_polling();
+ arch_cpu_idle_prepare();
+ cpu_idle_loop();
+}
--
1.8.4.108.g55ea5f6
^ permalink raw reply related
* Re: [PATCH v2 1/6] idle: move the cpuidle entry point to the generic idle loop
From: Nicolas Pitre @ 2014-01-30 16:07 UTC (permalink / raw)
To: Daniel Lezcano
Cc: linaro-kernel, Russell King, linux-pm, Peter Zijlstra, linux-sh,
Rafael J. Wysocki, linux-kernel, Olof Johansson, Paul Mundt,
Preeti U Murthy, Thomas Gleixner, linuxppc-dev, Ingo Molnar,
linux-arm-kernel
In-Reply-To: <52EA5720.8010000@linaro.org>
On Thu, 30 Jan 2014, Daniel Lezcano wrote:
> On 01/30/2014 06:28 AM, Nicolas Pitre wrote:
> > On Thu, 30 Jan 2014, Preeti U Murthy wrote:
> >
> > > Hi Nicolas,
> > >
> > > On 01/30/2014 02:01 AM, Nicolas Pitre wrote:
> > > > On Wed, 29 Jan 2014, Nicolas Pitre wrote:
> > > >
> > > > > In order to integrate cpuidle with the scheduler, we must have a
> > > > > better
> > > > > proximity in the core code with what cpuidle is doing and not delegate
> > > > > such interaction to arch code.
> > > > >
> > > > > Architectures implementing arch_cpu_idle() should simply enter
> > > > > a cheap idle mode in the absence of a proper cpuidle driver.
> > > > >
> > > > > Signed-off-by: Nicolas Pitre <nico@linaro.org>
> > > > > Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> > > >
> > > > As mentioned in my reply to Olof's comment on patch #5/6, here's a new
> > > > version of this patch adding the safety local_irq_enable() to the core
> > > > code.
> > > >
> > > > ----- >8
> > > >
> > > > From: Nicolas Pitre <nicolas.pitre@linaro.org>
> > > > Subject: idle: move the cpuidle entry point to the generic idle loop
> > > >
> > > > In order to integrate cpuidle with the scheduler, we must have a better
> > > > proximity in the core code with what cpuidle is doing and not delegate
> > > > such interaction to arch code.
> > > >
> > > > Architectures implementing arch_cpu_idle() should simply enter
> > > > a cheap idle mode in the absence of a proper cpuidle driver.
> > > >
> > > > In both cases i.e. whether it is a cpuidle driver or the default
> > > > arch_cpu_idle(), the calling convention expects IRQs to be disabled
> > > > on entry and enabled on exit. There is a warning in place already but
> > > > let's add a forced IRQ enable here as well. This will allow for
> > > > removing the forced IRQ enable some implementations do locally and
> > >
> > > Why would this patch allow for removing the forced IRQ enable that are
> > > being done on some archs in arch_cpu_idle()? Isn't this patch expecting
> > > the default arch_cpu_idle() to have re-enabled the interrupts after
> > > exiting from the default idle state? Its supposed to only catch faulty
> > > cpuidle drivers that haven't enabled IRQs on exit from idle state but
> > > are expected to have done so, isn't it?
> >
> > Exact. However x86 currently does this:
> >
> > if (cpuidle_idle_call())
> > x86_idle();
> > else
> > local_irq_enable();
> >
> > So whenever cpuidle_idle_call() is successful then IRQs are
> > unconditionally enabled whether or not the underlying cpuidle driver has
> > properly done it or not. And the reason is that some of the x86 cpuidle
> > do fail to enable IRQs before returning.
> >
> > So the idea is to get rid of this unconditional IRQ enabling and let the
> > core issue a warning instead (as well as enabling IRQs to allow the
> > system to run).
>
> But what I don't get with your comment is the local_irq_enable is done from
> the cpuidle common framework in 'cpuidle_enter_state' it is not done from the
> arch specific backend cpuidle driver.
Oh well... This certainly means we'll have to clean this mess as some
drivers do it on their own while some others don't. Some drivers also
loop on !need_resched() while some others simply return on the first
interrupt.
> So the code above could be:
>
> if (cpuidle_idle_call())
> x86_idle();
>
> without the else section, this local_irq_enable is pointless. Or may be I
> missed something ?
A later patch removes it anyway. But if it is really necessary to
enable interrupts then the core will do it but with a warning now.
Nicolas
^ permalink raw reply
* Re: [PATCH] slub: Don't throw away partial remote slabs if there is no local memory
From: Christoph Lameter @ 2014-01-30 16:26 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: Han Pingtian, mpm, penberg, linux-mm, cody, paulus,
Anton Blanchard, David Rientjes, Joonsoo Kim, linuxppc-dev,
Wanpeng Li
In-Reply-To: <20140129223640.GA10101@linux.vnet.ibm.com>
On Wed, 29 Jan 2014, Nishanth Aravamudan wrote:
> exactly what the caller intends.
>
> int searchnode = node;
> if (node == NUMA_NO_NODE)
> searchnode = numa_mem_id();
> if (!node_present_pages(node))
> searchnode = local_memory_node(node);
>
> The difference in semantics from the previous is that here, if we have a
> memoryless node, rather than using the CPU's nearest NUMA node, we use
> the NUMA node closest to the requested one?
The idea here is that the page allocator will do the fallback to other
nodes. This check for !node_present should not be necessary. SLUB needs to
accept the page from whatever node the page allocator returned and work
with that.
The problem is the check for having a slab from the "right" node may fall
again after another attempt to allocate from the same node. SLUB will then
push the slab from the *wrong* node back to the partial lists and may
attempt another allocation that will again be successful but return memory
from another node. That way the partial lists from a particular node are
growing uselessly.
One way to solve this may be to check if memory is actually allocated
from the requested node and fallback to NUMA_NO_NODE (which will use the
last allocated slab) for future allocs if the page allocator returned
memory from a different node (unless GFP_THIS_NODE is set of course).
Otherwise we end up replicating the page allocator logic in slub like in
slab. That is what I wanted to
avoid.
^ permalink raw reply
* Re: [PATCH v2 6/6] cpu/idle.c: move to sched/idle.c
From: Peter Zijlstra @ 2014-01-30 16:27 UTC (permalink / raw)
To: Nicolas Pitre
Cc: linaro-kernel, Russell King, linux-sh, linux-pm, Daniel Lezcano,
Rafael J. Wysocki, linux-kernel, Paul Mundt, Preeti U Murthy,
Thomas Gleixner, linuxppc-dev, Ingo Molnar, linux-arm-kernel
In-Reply-To: <alpine.LFD.2.11.1401301102210.1652@knanqh.ubzr>
On Thu, Jan 30, 2014 at 11:03:31AM -0500, Nicolas Pitre wrote:
> > This is not a valid patch for PATCH(1). Please try again.
>
> Don't you use git? ;-)
Nah, git and me don't get along well.
> Here's a plain patch:
Thanks!
^ permalink raw reply
* Re: [PATCH v2 6/6] cpu/idle.c: move to sched/idle.c
From: Joe Perches @ 2014-01-30 16:41 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Nicolas Pitre, linaro-kernel, Russell King, linux-sh, linux-pm,
Daniel Lezcano, Rafael J. Wysocki, linux-kernel, Paul Mundt,
Preeti U Murthy, Thomas Gleixner, linuxppc-dev, Ingo Molnar,
linux-arm-kernel
In-Reply-To: <20140130162753.GF5002@laptop.programming.kicks-ass.net>
On Thu, 2014-01-30 at 17:27 +0100, Peter Zijlstra wrote:
> On Thu, Jan 30, 2014 at 11:03:31AM -0500, Nicolas Pitre wrote:
> > > This is not a valid patch for PATCH(1). Please try again.
> >
> > Don't you use git? ;-)
>
> Nah, git and me don't get along well.
Perhaps you could use a newer version of patch
http://savannah.gnu.org/forum/forum.php?forum_id=7361
GNU patch version 2.7 released
Item posted by Andreas Gruenbacher <agruen> on Wed 12 Sep 2012 02:18:14
PM UTC.
I am pleased to announce that version 2.7 of GNU patch has been
released. The following significant changes have happened since the last
stable release in December 2009:
* Support for most features of the "diff --git" format, including
renames and copies, permission changes, and symlink diffs.
Binary diffs are not supported yet; patch will complain and skip
them.
^ permalink raw reply
* Re: [PATCH v2 6/6] cpu/idle.c: move to sched/idle.c
From: Peter Zijlstra @ 2014-01-30 16:52 UTC (permalink / raw)
To: Joe Perches
Cc: Nicolas Pitre, linaro-kernel, Russell King, linux-sh, linux-pm,
Daniel Lezcano, Rafael J. Wysocki, linux-kernel, Paul Mundt,
Preeti U Murthy, Thomas Gleixner, linuxppc-dev, Ingo Molnar,
linux-arm-kernel
In-Reply-To: <1391100076.2422.56.camel@joe-AO722>
On Thu, Jan 30, 2014 at 08:41:16AM -0800, Joe Perches wrote:
> Perhaps you could use a newer version of patch
>
> GNU patch version 2.7 released
Yeah, I know about that, I'll wait until its common in all distros,
updating all machines I use by hand is just painful.
^ permalink raw reply
* Re: [PATCH v2 1/6] idle: move the cpuidle entry point to the generic idle loop
From: Daniel Lezcano @ 2014-01-30 17:28 UTC (permalink / raw)
To: Nicolas Pitre
Cc: linaro-kernel, Russell King, linux-pm, Peter Zijlstra, linux-sh,
Rafael J. Wysocki, linux-kernel, Olof Johansson, Paul Mundt,
Preeti U Murthy, Thomas Gleixner, linuxppc-dev, Ingo Molnar,
linux-arm-kernel
In-Reply-To: <alpine.LFD.2.11.1401301056180.1652@knanqh.ubzr>
On 01/30/2014 05:07 PM, Nicolas Pitre wrote:
> On Thu, 30 Jan 2014, Daniel Lezcano wrote:
>
>> On 01/30/2014 06:28 AM, Nicolas Pitre wrote:
>>> On Thu, 30 Jan 2014, Preeti U Murthy wrote:
>>>
>>>> Hi Nicolas,
>>>>
>>>> On 01/30/2014 02:01 AM, Nicolas Pitre wrote:
>>>>> On Wed, 29 Jan 2014, Nicolas Pitre wrote:
>>>>>
>>>>>> In order to integrate cpuidle with the scheduler, we must have a
>>>>>> better
>>>>>> proximity in the core code with what cpuidle is doing and not delegate
>>>>>> such interaction to arch code.
>>>>>>
>>>>>> Architectures implementing arch_cpu_idle() should simply enter
>>>>>> a cheap idle mode in the absence of a proper cpuidle driver.
>>>>>>
>>>>>> Signed-off-by: Nicolas Pitre <nico@linaro.org>
>>>>>> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>>>>>
>>>>> As mentioned in my reply to Olof's comment on patch #5/6, here's a new
>>>>> version of this patch adding the safety local_irq_enable() to the core
>>>>> code.
>>>>>
>>>>> ----- >8
>>>>>
>>>>> From: Nicolas Pitre <nicolas.pitre@linaro.org>
>>>>> Subject: idle: move the cpuidle entry point to the generic idle loop
>>>>>
>>>>> In order to integrate cpuidle with the scheduler, we must have a better
>>>>> proximity in the core code with what cpuidle is doing and not delegate
>>>>> such interaction to arch code.
>>>>>
>>>>> Architectures implementing arch_cpu_idle() should simply enter
>>>>> a cheap idle mode in the absence of a proper cpuidle driver.
>>>>>
>>>>> In both cases i.e. whether it is a cpuidle driver or the default
>>>>> arch_cpu_idle(), the calling convention expects IRQs to be disabled
>>>>> on entry and enabled on exit. There is a warning in place already but
>>>>> let's add a forced IRQ enable here as well. This will allow for
>>>>> removing the forced IRQ enable some implementations do locally and
>>>>
>>>> Why would this patch allow for removing the forced IRQ enable that are
>>>> being done on some archs in arch_cpu_idle()? Isn't this patch expecting
>>>> the default arch_cpu_idle() to have re-enabled the interrupts after
>>>> exiting from the default idle state? Its supposed to only catch faulty
>>>> cpuidle drivers that haven't enabled IRQs on exit from idle state but
>>>> are expected to have done so, isn't it?
>>>
>>> Exact. However x86 currently does this:
>>>
>>> if (cpuidle_idle_call())
>>> x86_idle();
>>> else
>>> local_irq_enable();
>>>
>>> So whenever cpuidle_idle_call() is successful then IRQs are
>>> unconditionally enabled whether or not the underlying cpuidle driver has
>>> properly done it or not. And the reason is that some of the x86 cpuidle
>>> do fail to enable IRQs before returning.
>>>
>>> So the idea is to get rid of this unconditional IRQ enabling and let the
>>> core issue a warning instead (as well as enabling IRQs to allow the
>>> system to run).
>>
>> But what I don't get with your comment is the local_irq_enable is done from
>> the cpuidle common framework in 'cpuidle_enter_state' it is not done from the
>> arch specific backend cpuidle driver.
>
> Oh well... This certainly means we'll have to clean this mess as some
> drivers do it on their own while some others don't. Some drivers also
> loop on !need_resched() while some others simply return on the first
> interrupt.
Ok, I think the mess is coming from 'default_idle' which does not
re-enable the local_irq but used from different places like
amd_e400_idle and apm_cpu_idle.
void default_idle(void)
{
trace_cpu_idle_rcuidle(1, smp_processor_id());
safe_halt();
trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, smp_processor_id());
}
Considering the system configured without cpuidle because this one
*always* enable the local irq, we have the different cases:
x86_idle = default_idle();
==> local_irq_enable is missing
x86_idle = amd_e400_idle();
==> it calls local_irq_disable(); but in the idle loop context where the
local irqs are already disabled.
==> if amd_e400_c1e_detected is true, the local_irq are enabled
==> otherwise no
==> default_idle is called from there and does not enable local_irqs
>> So the code above could be:
>>
>> if (cpuidle_idle_call())
>> x86_idle();
>>
>> without the else section, this local_irq_enable is pointless. Or may be I
>> missed something ?
>
> A later patch removes it anyway. But if it is really necessary to
> enable interrupts then the core will do it but with a warning now.
This WARN should disappear. It was there because it was up to the
backend cpuidle driver to enable the irq. But in the meantime, that was
consolidated into a single place in the cpuidle framework so no need to
try to catch errors.
What about (based on this patchset).
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 4505e2a..2d60cbb 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -299,6 +299,7 @@ void arch_cpu_idle_dead(void)
void arch_cpu_idle(void)
{
x86_idle();
+ local_irq_enable();
}
/*
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply related
* Re: [PATCH 2/2] Fix compile error of pgtable-ppc64.h
From: Aneesh Kumar K.V @ 2014-01-30 17:38 UTC (permalink / raw)
To: Greg KH, Benjamin Herrenschmidt; +Cc: paulus, linuxppc-dev, Li Zhong, stable
In-Reply-To: <20140130123457.GA6571@kroah.com>
Greg KH <greg@kroah.com> writes:
> On Thu, Jan 30, 2014 at 09:57:36AM +1100, Benjamin Herrenschmidt wrote:
>> On Wed, 2014-01-29 at 10:45 -0800, Greg KH wrote:
>> > On Tue, Jan 28, 2014 at 05:52:42PM +0530, Aneesh Kumar K.V wrote:
>> > > From: Li Zhong <zhong@linux.vnet.ibm.com>
>> > >
>> > > It seems that forward declaration couldn't work well with typedef, use
>> > > struct spinlock directly to avoiding following build errors:
>> > >
>> > > In file included from include/linux/spinlock.h:81,
>> > > from include/linux/seqlock.h:35,
>> > > from include/linux/time.h:5,
>> > > from include/uapi/linux/timex.h:56,
>> > > from include/linux/timex.h:56,
>> > > from include/linux/sched.h:17,
>> > > from arch/powerpc/kernel/asm-offsets.c:17:
>> > > include/linux/spinlock_types.h:76: error: redefinition of typedef 'spinlock_t'
>> > > /root/linux-next/arch/powerpc/include/asm/pgtable-ppc64.h:563: note: previous declaration of 'spinlock_t' was here
>> > >
>> > > build fix for upstream SHA1: b3084f4db3aeb991c507ca774337c7e7893ed04f
>> > > for 3.13 stable series
>> >
>> > I don't understand, why is this needed? Is there a corrisponding patch
>> > upstream that already does this? What went wrong with a "normal"
>> > backport of the patch to 3.13?
>>
>> There's a corresponding patch in powerpc-next that I'm about to send to
>> Linus today, but for the backport, the "fix" could be folded into the
>> original offending patch.
>
> Oh come on, you know better than to try to send me a patch that isn't in
> Linus's tree already. Crap, I can't take that at all.
>
> Send me the git commit id when it is in Linus's tree, otherwise I'm not
> taking it.
>
> And no, don't "fold in" anything, that's not ok either. I'll just go
> drop this patch entirely from all of my -stable trees for now. Feel
> free to resend them when all of the needed stuff is upstream.
The fix for mremap crash is already in Linus tree. It is the build
failure for older gcc compiler version that is not in linus tree. We
missed that in the first pull request. Do we really need to drop the
patch from 3.11 and 3.12 trees ? The patch their is a variant, and don't
require this build fix.
-aneesh
^ permalink raw reply
* Re: [PATCH 2/2] Fix compile error of pgtable-ppc64.h
From: Greg KH @ 2014-01-30 17:55 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev, stable, paulus, Li Zhong
In-Reply-To: <8761p15pzn.fsf@linux.vnet.ibm.com>
On Thu, Jan 30, 2014 at 11:08:52PM +0530, Aneesh Kumar K.V wrote:
> Greg KH <greg@kroah.com> writes:
>
> > On Thu, Jan 30, 2014 at 09:57:36AM +1100, Benjamin Herrenschmidt wrote:
> >> On Wed, 2014-01-29 at 10:45 -0800, Greg KH wrote:
> >> > On Tue, Jan 28, 2014 at 05:52:42PM +0530, Aneesh Kumar K.V wrote:
> >> > > From: Li Zhong <zhong@linux.vnet.ibm.com>
> >> > >
> >> > > It seems that forward declaration couldn't work well with typedef, use
> >> > > struct spinlock directly to avoiding following build errors:
> >> > >
> >> > > In file included from include/linux/spinlock.h:81,
> >> > > from include/linux/seqlock.h:35,
> >> > > from include/linux/time.h:5,
> >> > > from include/uapi/linux/timex.h:56,
> >> > > from include/linux/timex.h:56,
> >> > > from include/linux/sched.h:17,
> >> > > from arch/powerpc/kernel/asm-offsets.c:17:
> >> > > include/linux/spinlock_types.h:76: error: redefinition of typedef 'spinlock_t'
> >> > > /root/linux-next/arch/powerpc/include/asm/pgtable-ppc64.h:563: note: previous declaration of 'spinlock_t' was here
> >> > >
> >> > > build fix for upstream SHA1: b3084f4db3aeb991c507ca774337c7e7893ed04f
> >> > > for 3.13 stable series
> >> >
> >> > I don't understand, why is this needed? Is there a corrisponding patch
> >> > upstream that already does this? What went wrong with a "normal"
> >> > backport of the patch to 3.13?
> >>
> >> There's a corresponding patch in powerpc-next that I'm about to send to
> >> Linus today, but for the backport, the "fix" could be folded into the
> >> original offending patch.
> >
> > Oh come on, you know better than to try to send me a patch that isn't in
> > Linus's tree already. Crap, I can't take that at all.
> >
> > Send me the git commit id when it is in Linus's tree, otherwise I'm not
> > taking it.
> >
> > And no, don't "fold in" anything, that's not ok either. I'll just go
> > drop this patch entirely from all of my -stable trees for now. Feel
> > free to resend them when all of the needed stuff is upstream.
>
> The fix for mremap crash is already in Linus tree.
What is the git commit id?
> It is the build failure for older gcc compiler version that is not in
> linus tree.
That is what I can not take.
> We missed that in the first pull request. Do we really need to drop
> the patch from 3.11 and 3.12 trees ?
I already did.
> The patch their is a variant, and don't require this build fix.
Don't give me a "variant", give me the exact same patch, only changed to
handle the fuzz/differences of older kernels, don't make different
changes to the original patch to make up for things you found out later
on, otherwise everyone is confused as to why the fix for the fix is not
in the tree.
So, when both patches get in Linus's tree, please send me the properly
backported patches and I'll be glad to apply them.
greg k-h
^ permalink raw reply
* Re: [PATCH 2/2] Fix compile error of pgtable-ppc64.h
From: Aneesh Kumar K.V @ 2014-01-30 18:03 UTC (permalink / raw)
To: Greg KH; +Cc: paulus, linuxppc-dev, Li Zhong, stable
In-Reply-To: <20140130175514.GA29370@kroah.com>
Greg KH <greg@kroah.com> writes:
> On Thu, Jan 30, 2014 at 11:08:52PM +0530, Aneesh Kumar K.V wrote:
>> Greg KH <greg@kroah.com> writes:
>>
>> > On Thu, Jan 30, 2014 at 09:57:36AM +1100, Benjamin Herrenschmidt wrote:
>> >> On Wed, 2014-01-29 at 10:45 -0800, Greg KH wrote:
>> >> > On Tue, Jan 28, 2014 at 05:52:42PM +0530, Aneesh Kumar K.V wrote:
>> >> > > From: Li Zhong <zhong@linux.vnet.ibm.com>
>> >> > >
>> >> > > It seems that forward declaration couldn't work well with typedef, use
>> >> > > struct spinlock directly to avoiding following build errors:
>> >> > >
>> >> > > In file included from include/linux/spinlock.h:81,
>> >> > > from include/linux/seqlock.h:35,
>> >> > > from include/linux/time.h:5,
>> >> > > from include/uapi/linux/timex.h:56,
>> >> > > from include/linux/timex.h:56,
>> >> > > from include/linux/sched.h:17,
>> >> > > from arch/powerpc/kernel/asm-offsets.c:17:
>> >> > > include/linux/spinlock_types.h:76: error: redefinition of typedef 'spinlock_t'
>> >> > > /root/linux-next/arch/powerpc/include/asm/pgtable-ppc64.h:563: note: previous declaration of 'spinlock_t' was here
>> >> > >
>> >> > > build fix for upstream SHA1: b3084f4db3aeb991c507ca774337c7e7893ed04f
>> >> > > for 3.13 stable series
>> >> >
>> >> > I don't understand, why is this needed? Is there a corrisponding patch
>> >> > upstream that already does this? What went wrong with a "normal"
>> >> > backport of the patch to 3.13?
>> >>
>> >> There's a corresponding patch in powerpc-next that I'm about to send to
>> >> Linus today, but for the backport, the "fix" could be folded into the
>> >> original offending patch.
>> >
>> > Oh come on, you know better than to try to send me a patch that isn't in
>> > Linus's tree already. Crap, I can't take that at all.
>> >
>> > Send me the git commit id when it is in Linus's tree, otherwise I'm not
>> > taking it.
>> >
>> > And no, don't "fold in" anything, that's not ok either. I'll just go
>> > drop this patch entirely from all of my -stable trees for now. Feel
>> > free to resend them when all of the needed stuff is upstream.
>>
>> The fix for mremap crash is already in Linus tree.
>
> What is the git commit id?
upstream SHA1: b3084f4db3aeb991c507ca774337c7e7893ed04f
That is patch 1 in this series.
>
>> It is the build failure for older gcc compiler version that is not in
>> linus tree.
>
> That is what I can not take.
>
>> We missed that in the first pull request. Do we really need to drop
>> the patch from 3.11 and 3.12 trees ?
>
> I already did.
>
>> The patch their is a variant, and don't require this build fix.
>
> Don't give me a "variant", give me the exact same patch, only changed to
> handle the fuzz/differences of older kernels, don't make different
> changes to the original patch to make up for things you found out later
> on, otherwise everyone is confused as to why the fix for the fix is not
> in the tree.
In this specific case it may be difficult. 3.13 have other changes
around the code path. It has split pmd locks etc which result in us
doing a withdraw and deposit even on x86. For 3.11 and 3.12, we need to
do that extra withdraw and deposit only for ppc64. Hence the variant
which used #ifdef around that code.
>
> So, when both patches get in Linus's tree, please send me the properly
> backported patches and I'll be glad to apply them.
>
-aneesh
^ permalink raw reply
* Re: [PATCH v2 1/6] idle: move the cpuidle entry point to the generic idle loop
From: Peter Zijlstra @ 2014-01-30 18:06 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Nicolas Pitre, linaro-kernel, Russell King, linux-pm, linux-sh,
Rafael J. Wysocki, linux-kernel, Olof Johansson, Paul Mundt,
Preeti U Murthy, Thomas Gleixner, linuxppc-dev, Ingo Molnar,
linux-arm-kernel
In-Reply-To: <52EA8BD4.6020803@linaro.org>
On Thu, Jan 30, 2014 at 06:28:52PM +0100, Daniel Lezcano wrote:
> Ok, I think the mess is coming from 'default_idle' which does not re-enable
> the local_irq but used from different places like amd_e400_idle and
> apm_cpu_idle.
>
> void default_idle(void)
> {
> trace_cpu_idle_rcuidle(1, smp_processor_id());
> safe_halt();
> trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, smp_processor_id());
> }
>
> Considering the system configured without cpuidle because this one *always*
> enable the local irq, we have the different cases:
>
> x86_idle = default_idle();
> ==> local_irq_enable is missing
>
safe_halt() is "sti; hlt" and so very much does the irq_enable.
^ permalink raw reply
* [PATCH] powerpc/pseries: Disable relocation on exception while going down during crash.
From: Mahesh J Salgaonkar @ 2014-01-30 19:00 UTC (permalink / raw)
To: linuxppc-dev, Benjamin Herrenschmidt
Cc: Steve Best, Paul Mackerras, Anton Blanchard, Hari Bathini
From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Disable relocation on exception while going down even in kdump case. This
is because we are about clear htab mappings while kexec-ing into kdump
kernel and we may run into issues if we still have AIL ON.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/setup.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index c1f1908..3925173 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -430,8 +430,7 @@ static void pSeries_machine_kexec(struct kimage *image)
{
long rc;
- if (firmware_has_feature(FW_FEATURE_SET_MODE) &&
- (image->type != KEXEC_TYPE_CRASH)) {
+ if (firmware_has_feature(FW_FEATURE_SET_MODE)) {
rc = pSeries_disable_reloc_on_exc();
if (rc != H_SUCCESS)
pr_warning("Warning: Failed to disable relocation on "
^ permalink raw reply related
* [PATCH] powerpc: Fix kdump hang issue on p8 with relocation on exception enabled.
From: Mahesh J Salgaonkar @ 2014-01-30 19:01 UTC (permalink / raw)
To: linuxppc-dev, Benjamin Herrenschmidt
Cc: Steve Best, Paul Mackerras, Anton Blanchard, Hari Bathini
From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
On p8 systems, with relocation on exception feature enabled we are seeing
kdump kernel hang at interrupt vector 0xc*4400. The reason is, with this
feature enabled, exception are raised with MMU (IR=DR=1) ON with the
default offset of 0xc*4000. Since exception is raised in virtual mode it
requires the vector region to be executable without which it fails to
fetch and execute instruction at 0xc*4xxx. For default kernel since kernel
is loaded at real 0, the htab mappings sets the entire kernel text region
executable. But for relocatable kernel (e.g. kdump case) we only copy
interrupt vectors down to real 0 and never marked that region as
executable because in p7 and below we always get exception in real mode.
This patch fixes this issue by marking htab mapping range as executable
that overlaps with the interrupt vector region for relocatable kernel.
Thanks to Ben who helped me to debug this issue and find the root cause.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/sections.h | 12 ++++++++++++
arch/powerpc/mm/hash_utils_64.c | 14 ++++++++++++++
2 files changed, 26 insertions(+)
diff --git a/arch/powerpc/include/asm/sections.h b/arch/powerpc/include/asm/sections.h
index 4ee06fe..d0e784e 100644
--- a/arch/powerpc/include/asm/sections.h
+++ b/arch/powerpc/include/asm/sections.h
@@ -8,6 +8,7 @@
#ifdef __powerpc64__
+extern char __start_interrupts[];
extern char __end_interrupts[];
extern char __prom_init_toc_start[];
@@ -21,6 +22,17 @@ static inline int in_kernel_text(unsigned long addr)
return 0;
}
+static inline int overlaps_interrupt_vector_text(unsigned long start,
+ unsigned long end)
+{
+ unsigned long real_start, real_end;
+ real_start = __start_interrupts - _stext;
+ real_end = __end_interrupts - _stext;
+
+ return start < (unsigned long)__va(real_end) &&
+ (unsigned long)__va(real_start) < end;
+}
+
static inline int overlaps_kernel_text(unsigned long start, unsigned long end)
{
return start < (unsigned long)__init_end &&
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 6176b3c..50e21af 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -206,6 +206,20 @@ int htab_bolt_mapping(unsigned long vstart, unsigned long vend,
if (overlaps_kernel_text(vaddr, vaddr + step))
tprot &= ~HPTE_R_N;
+ /*
+ * If relocatable, check if it overlaps interrupt vectors that
+ * are copied down to real 0. For relocatable kernel
+ * (e.g. kdump case) we copy interrupt vectors down to real
+ * address 0. Mark that region as executable. This is
+ * because on p8 system with relocation on exception feature
+ * enabled, exceptions are raised with MMU (IR=DR=1) ON. Hence
+ * in order to execute the interrupt handlers in virtual
+ * mode the vector region need to be marked as executable.
+ */
+ if ((PHYSICAL_START > MEMORY_START) &&
+ overlaps_interrupt_vector_text(vaddr, vaddr + step))
+ tprot &= ~HPTE_R_N;
+
hash = hpt_hash(vpn, shift, ssize);
hpteg = ((hash & htab_hash_mask) * HPTES_PER_GROUP);
^ permalink raw reply related
* Re: [PATCH v2 1/6] idle: move the cpuidle entry point to the generic idle loop
From: Nicolas Pitre @ 2014-01-30 19:24 UTC (permalink / raw)
To: Daniel Lezcano
Cc: linaro-kernel, Russell King, linux-pm, Peter Zijlstra, linux-sh,
Rafael J. Wysocki, linux-kernel, Olof Johansson, Paul Mundt,
Preeti U Murthy, Thomas Gleixner, linuxppc-dev, Ingo Molnar,
linux-arm-kernel
In-Reply-To: <52EA8BD4.6020803@linaro.org>
On Thu, 30 Jan 2014, Daniel Lezcano wrote:
> On 01/30/2014 05:07 PM, Nicolas Pitre wrote:
> > On Thu, 30 Jan 2014, Daniel Lezcano wrote:
> > > But what I don't get with your comment is the local_irq_enable is done
> > > from
> > > the cpuidle common framework in 'cpuidle_enter_state' it is not done from
> > > the
> > > arch specific backend cpuidle driver.
> >
> > Oh well... This certainly means we'll have to clean this mess as some
> > drivers do it on their own while some others don't. Some drivers also
> > loop on !need_resched() while some others simply return on the first
> > interrupt.
>
> Ok, I think the mess is coming from 'default_idle' which does not re-enable
> the local_irq but used from different places like amd_e400_idle and
> apm_cpu_idle.
Yet if you look at the code path before my patches you'll see that IRQs
were enabled only after cpuidle_idle_call() had returned success.
> void default_idle(void)
> {
> trace_cpu_idle_rcuidle(1, smp_processor_id());
> safe_halt();
> trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, smp_processor_id());
> }
>
> Considering the system configured without cpuidle because this one *always*
> enable the local irq,
Yet this is discutable. Given that some hardware do have IRQs turned on
upon exiting idle mode, I think we should generalize it so that
the explicit enabling
of IRQs, when needed, should be done as close as possible to the
operation that caused idle mode to be entered.
> we have the different cases:
>
> x86_idle = default_idle();
> ==> local_irq_enable is missing
According to Peter it is not.
> x86_idle = amd_e400_idle();
> ==> it calls local_irq_disable(); but in the idle loop context where the
> local irqs are already disabled.
Since it returned from default_idle() then IRQs are enabled.
> ==> if amd_e400_c1e_detected is true, the local_irq are enabled
> ==> otherwise no
> ==> default_idle is called from there and does not enable local_irqs
Again, it does.
> > > So the code above could be:
> > >
> > > if (cpuidle_idle_call())
> > > x86_idle();
> > >
> > > without the else section, this local_irq_enable is pointless. Or may be I
> > > missed something ?
> >
> > A later patch removes it anyway. But if it is really necessary to
> > enable interrupts then the core will do it but with a warning now.
>
> This WARN should disappear. It was there because it was up to the backend
> cpuidle driver to enable the irq. But in the meantime, that was consolidated
> into a single place in the cpuidle framework so no need to try to catch
> errors.
And that consolidation was a mistake IMHO. We should assume that the
exiting of idle mode has IRQs enabled already, and do so manually in the
backend driver if it is not the case on particular hardware. That's the
only way to ensure uniformity at a higher level.
Yet, if a code path is buggy in that regard, whether this is through
cpuidle when enabled, or the default idle function otherwise, then the
warning is there in cpu_idle_loop() to catch them all.
> What about (based on this patchset).
>
> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> index 4505e2a..2d60cbb 100644
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -299,6 +299,7 @@ void arch_cpu_idle_dead(void)
> void arch_cpu_idle(void)
> {
> x86_idle();
> + local_irq_enable();
> }
Again this is redundant.
Nicolas
^ permalink raw reply
* Re: [PATCH 2/2] Fix compile error of pgtable-ppc64.h
From: Benjamin Herrenschmidt @ 2014-01-30 20:59 UTC (permalink / raw)
To: Greg KH; +Cc: paulus, linuxppc-dev, Aneesh Kumar K.V, stable, Li Zhong
In-Reply-To: <20140130175514.GA29370@kroah.com>
On Thu, 2014-01-30 at 09:55 -0800, Greg KH wrote:
> On Thu, Jan 30, 2014 at 11:08:52PM +0530, Aneesh Kumar K.V wrote:
> > Greg KH <greg@kroah.com> writes:
> >
> > > On Thu, Jan 30, 2014 at 09:57:36AM +1100, Benjamin Herrenschmidt wrote:
> > >> On Wed, 2014-01-29 at 10:45 -0800, Greg KH wrote:
> > >> > On Tue, Jan 28, 2014 at 05:52:42PM +0530, Aneesh Kumar K.V wrote:
> > >> > > From: Li Zhong <zhong@linux.vnet.ibm.com>
> > >> > >
> > >> > > It seems that forward declaration couldn't work well with typedef, use
> > >> > > struct spinlock directly to avoiding following build errors:
> > >> > >
> > >> > > In file included from include/linux/spinlock.h:81,
> > >> > > from include/linux/seqlock.h:35,
> > >> > > from include/linux/time.h:5,
> > >> > > from include/uapi/linux/timex.h:56,
> > >> > > from include/linux/timex.h:56,
> > >> > > from include/linux/sched.h:17,
> > >> > > from arch/powerpc/kernel/asm-offsets.c:17:
> > >> > > include/linux/spinlock_types.h:76: error: redefinition of typedef 'spinlock_t'
> > >> > > /root/linux-next/arch/powerpc/include/asm/pgtable-ppc64.h:563: note: previous declaration of 'spinlock_t' was here
> > >> > >
> > >> > > build fix for upstream SHA1: b3084f4db3aeb991c507ca774337c7e7893ed04f
> > >> > > for 3.13 stable series
> > >> >
> > >> > I don't understand, why is this needed? Is there a corrisponding patch
> > >> > upstream that already does this? What went wrong with a "normal"
> > >> > backport of the patch to 3.13?
> > >>
> > >> There's a corresponding patch in powerpc-next that I'm about to send to
> > >> Linus today, but for the backport, the "fix" could be folded into the
> > >> original offending patch.
> > >
> > > Oh come on, you know better than to try to send me a patch that isn't in
> > > Linus's tree already. Crap, I can't take that at all.
> > >
> > > Send me the git commit id when it is in Linus's tree, otherwise I'm not
> > > taking it.
> > >
> > > And no, don't "fold in" anything, that's not ok either. I'll just go
> > > drop this patch entirely from all of my -stable trees for now. Feel
> > > free to resend them when all of the needed stuff is upstream.
> >
> > The fix for mremap crash is already in Linus tree.
>
> What is the git commit id?
Relax Greg :-) The submissions all had the commit ID of the original
patch upsteam: b3084f4db3aeb991c507ca774337c7e7893ed04f
The only *thing* here is due to churn upstream in 3.13, the backport
is a bit different for 3.13 vs. earlier versions.
The earlier ones are perfectly kosher and you should have no reason
not to take them.
The 3.13, well, Mahesh was a bit quick here, he sent you the actual
patch that went upstream ... and a second patch to fix a problem
with older gcc's that it introduces. Because it's a simple build fix of
the previous patch, I suggested folding it in instead.
That build fix is what is not yet upstream, it's in my -next branch
which Linus hasn't pulled just yet.
If that's an issue for you, just drop the 3.13 variant of the patch and
we'll send it again with the build fix as soon as Linus has pulled the
latter.
> > It is the build failure for older gcc compiler version that is not in
> > linus tree.
>
> That is what I can not take.
>
> > We missed that in the first pull request. Do we really need to drop
> > the patch from 3.11 and 3.12 trees ?
>
> I already did.
>
> > The patch their is a variant, and don't require this build fix.
>
> Don't give me a "variant", give me the exact same patch, only changed to
> handle the fuzz/differences of older kernels, don't make different
> changes to the original patch to make up for things you found out later
> on, otherwise everyone is confused as to why the fix for the fix is not
> in the tree.
The backport patch is a "variant" because of changes in the affected
function that went into 3.13.
> So, when both patches get in Linus's tree, please send me the properly
> backported patches and I'll be glad to apply them.
Ben.
^ permalink raw reply
* Re: [PATCH 1/2][v7] driver/memory:Move Freescale IFC driver to a common driver
From: Scott Wood @ 2014-01-30 21:31 UTC (permalink / raw)
To: Prabhakar Kushwaha; +Cc: linuxppc-dev
In-Reply-To: <1390886979-9341-1-git-send-email-prabhakar@freescale.com>
On Tue, 2014-01-28 at 10:59 +0530, Prabhakar Kushwaha wrote:
> Freescale IFC controller has been used for mpc8xxx. It will be used
> for ARM-based SoC as well. This patch moves the driver to driver/memory
> and fix the header file includes.
>
> Also remove module_platform_driver() and instead call
> platform_driver_register() from subsys_initcall() to make sure this module
> has been loaded before MTD partition parsing starts.
>
> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
When did Arnd ack this? Especially in v7 form... and I don't see him on
CC.
> +config FSL_IFC
> + bool "Freescale Integrated Flash Controller"
> + depends on FSL_SOC
> + help
> + This driver is for the Integrated Flash Controller Controller(IFC)
Controller Controller?
> + module available in Freescale SoCs. This controller allows to handle flash
> + devices such as NOR, NAND, FPGA and ASIC etc
FPGA and ASIC are not (necessarily) flash devices.
-Scott
^ permalink raw reply
* Re: [PATCH 2/2] Fix compile error of pgtable-ppc64.h
From: Greg KH @ 2014-01-30 22:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: paulus, linuxppc-dev, Aneesh Kumar K.V, stable, Li Zhong
In-Reply-To: <1391115541.29634.15.camel@pasglop>
On Fri, Jan 31, 2014 at 07:59:01AM +1100, Benjamin Herrenschmidt wrote:
> If that's an issue for you, just drop the 3.13 variant of the patch and
> we'll send it again with the build fix as soon as Linus has pulled the
> latter.
I have done that.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] powerpc/eeh: drop taken reference to driver on eeh_rmv_device
From: Gavin Shan @ 2014-01-31 0:46 UTC (permalink / raw)
To: Thadeu Lima de Souza Cascardo; +Cc: linuxppc-dev, shangw, paulus
In-Reply-To: <1391086848-11311-1-git-send-email-cascardo@linux.vnet.ibm.com>
On Thu, Jan 30, 2014 at 11:00:48AM -0200, Thadeu Lima de Souza Cascardo wrote:
>Commit f5c57710dd62dd06f176934a8b4b8accbf00f9f8 ("powerpc/eeh: Use
>partial hotplug for EEH unaware drivers") introduces eeh_rmv_device,
>which may grab a reference to a driver, but not release it.
>
>That prevents a driver from being removed after it has gone through EEH
>recovery.
>
>This patch drops the reference in either exit path if it was taken.
>
>Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
>---
> arch/powerpc/kernel/eeh_driver.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
>diff --git a/arch/powerpc/kernel/eeh_driver.c b/arch/powerpc/kernel/eeh_driver.c
>index 7bb30dc..afe7337 100644
>--- a/arch/powerpc/kernel/eeh_driver.c
>+++ b/arch/powerpc/kernel/eeh_driver.c
>@@ -364,7 +364,7 @@ static void *eeh_rmv_device(void *data, void *userdata)
> return NULL;
> driver = eeh_pcid_get(dev);
> if (driver && driver->err_handler)
>- return NULL;
>+ goto out;
>
> /* Remove it from PCI subsystem */
> pr_debug("EEH: Removing %s without EEH sensitive driver\n",
>@@ -377,6 +377,9 @@ static void *eeh_rmv_device(void *data, void *userdata)
For normal case (driver without EEH support), we probably release the reference
to the driver before pci_stop_and_remove_bus_device().
> pci_stop_and_remove_bus_device(dev);
> pci_unlock_rescan_remove();
>
>+out:
>+ if (driver)
>+ eeh_pcid_put(dev);
> return NULL;
We needn't "if (driver)" here as eeh_pcid_put() already had the check.
> }
>
Thanks,
Gavin
^ permalink raw reply
* RE: [PATCH 1/2][v7] driver/memory:Move Freescale IFC driver to a common driver
From: prabhakar @ 2014-01-31 3:23 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1391117477.6733.39.camel@snotra.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogRnJpZGF5LCBKYW51YXJ5IDMxLCAyMDE0IDM6MDEgQU0NCj4gVG86IEt1c2h3
YWhhIFByYWJoYWthci1CMzI1NzkNCj4gQ2M6IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3Jn
DQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMS8yXVt2N10gZHJpdmVyL21lbW9yeTpNb3ZlIEZyZWVz
Y2FsZSBJRkMgZHJpdmVyIHRvIGEgY29tbW9uDQo+IGRyaXZlcg0KPiANCj4gT24gVHVlLCAyMDE0
LTAxLTI4IGF0IDEwOjU5ICswNTMwLCBQcmFiaGFrYXIgS3VzaHdhaGEgd3JvdGU6DQo+ID4gIEZy
ZWVzY2FsZSBJRkMgY29udHJvbGxlciBoYXMgYmVlbiB1c2VkIGZvciBtcGM4eHh4LiBJdCB3aWxs
IGJlIHVzZWQNCj4gPiBmb3IgQVJNLWJhc2VkIFNvQyBhcyB3ZWxsLiBUaGlzIHBhdGNoIG1vdmVz
IHRoZSBkcml2ZXIgdG8NCj4gPiBkcml2ZXIvbWVtb3J5ICBhbmQgZml4IHRoZSBoZWFkZXIgZmls
ZSBpbmNsdWRlcy4NCj4gPg0KPiA+ICBBbHNvIHJlbW92ZSBtb2R1bGVfcGxhdGZvcm1fZHJpdmVy
KCkgYW5kICBpbnN0ZWFkIGNhbGwNCj4gPiAgcGxhdGZvcm1fZHJpdmVyX3JlZ2lzdGVyKCkgZnJv
bSBzdWJzeXNfaW5pdGNhbGwoKSB0byBtYWtlIHN1cmUgdGhpcw0KPiA+IG1vZHVsZSAgaGFzIGJl
ZW4gbG9hZGVkIGJlZm9yZSBNVEQgcGFydGl0aW9uIHBhcnNpbmcgc3RhcnRzLg0KPiA+DQo+ID4g
U2lnbmVkLW9mZi1ieTogUHJhYmhha2FyIEt1c2h3YWhhIDxwcmFiaGFrYXJAZnJlZXNjYWxlLmNv
bT4NCj4gPiBBY2tlZC1ieTogQXJuZCBCZXJnbWFubiA8YXJuZEBhcm5kYi5kZT4NCj4gDQo+IFdo
ZW4gZGlkIEFybmQgYWNrIHRoaXM/ICBFc3BlY2lhbGx5IGluIHY3IGZvcm0uLi4gYW5kIEkgZG9u
J3Qgc2VlIGhpbSBvbiBDQy4NCj4gDQo+ID4gK2NvbmZpZyBGU0xfSUZDDQo+ID4gKwlib29sICJG
cmVlc2NhbGUgSW50ZWdyYXRlZCBGbGFzaCBDb250cm9sbGVyIg0KPiA+ICsJZGVwZW5kcyBvbiBG
U0xfU09DDQo+ID4gKwloZWxwDQo+ID4gKwkgIFRoaXMgZHJpdmVyIGlzIGZvciB0aGUgSW50ZWdy
YXRlZCBGbGFzaCBDb250cm9sbGVyIENvbnRyb2xsZXIoSUZDKQ0KPiANCj4gQ29udHJvbGxlciBD
b250cm9sbGVyPw0KDQpJIHdpbGwgZml4IGl0DQoNCj4gDQo+ID4gKwkgIG1vZHVsZSBhdmFpbGFi
bGUgaW4gRnJlZXNjYWxlIFNvQ3MuIFRoaXMgY29udHJvbGxlciBhbGxvd3MgdG8gaGFuZGxlDQo+
IGZsYXNoDQo+ID4gKwkgIGRldmljZXMgc3VjaCBhcyBOT1IsIE5BTkQsIEZQR0EgYW5kIEFTSUMg
ZXRjDQo+IA0KPiBGUEdBIGFuZCBBU0lDIGFyZSBub3QgKG5lY2Vzc2FyaWx5KSBmbGFzaCBkZXZp
Y2VzLg0KPiANCg0KWWVzIGl0IHRydWUuIA0KSSBhbSBub3Qgc3VyZSB0aGlzIGZvbGRlciBpcyBv
bmx5IGZvciBmbGFzaCBjb250cm9sbGVyLg0KSSBjYW4gc2VlIHJlZmVyZW5jZXMgb2YgRlBHQSwg
U1JBTSBpbiBzYW1lIEtjb25maWdzLiANCg0KUmVnYXJkcywNClByYWJoYWthcg0K
^ permalink raw reply
* Re: [PATCH 1/2][v7] driver/memory:Move Freescale IFC driver to a common driver
From: Scott Wood @ 2014-01-31 3:47 UTC (permalink / raw)
To: Kushwaha Prabhakar-B32579; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <cc597cc6590e4eb7b7d6fbc004fbf749@DM2PR03MB464.namprd03.prod.outlook.com>
On Thu, 2014-01-30 at 21:23 -0600, Kushwaha Prabhakar-B32579 wrote:
>
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Friday, January 31, 2014 3:01 AM
> > To: Kushwaha Prabhakar-B32579
> > Cc: linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [PATCH 1/2][v7] driver/memory:Move Freescale IFC driver to a common
> > driver
> >
> > On Tue, 2014-01-28 at 10:59 +0530, Prabhakar Kushwaha wrote:
> > > Freescale IFC controller has been used for mpc8xxx. It will be used
> > > for ARM-based SoC as well. This patch moves the driver to
> > > driver/memory and fix the header file includes.
> > >
> > > Also remove module_platform_driver() and instead call
> > > platform_driver_register() from subsys_initcall() to make sure this
> > > module has been loaded before MTD partition parsing starts.
> > >
> > > Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
> > > Acked-by: Arnd Bergmann <arnd@arndb.de>
> >
> > When did Arnd ack this? Especially in v7 form... and I don't see him on CC.
> >
> > > +config FSL_IFC
> > > + bool "Freescale Integrated Flash Controller"
> > > + depends on FSL_SOC
> > > + help
> > > + This driver is for the Integrated Flash Controller Controller(IFC)
> >
> > Controller Controller?
>
> I will fix it
>
> >
> > > + module available in Freescale SoCs. This controller allows to handle
> > flash
> > > + devices such as NOR, NAND, FPGA and ASIC etc
> >
> > FPGA and ASIC are not (necessarily) flash devices.
> >
>
> Yes it true.
> I am not sure this folder is only for flash controller.
> I can see references of FPGA, SRAM in same Kconfigs.
Right, just fix the help text.
s/handle flash devices/handle devices/
-Scott
^ permalink raw reply
* [PATCH 0/3] powerpc: Free up an IPI message slot for tick broadcast IPIs
From: Preeti U Murthy @ 2014-01-31 4:09 UTC (permalink / raw)
To: deepthi, svaidy, toshi.kani, arnd, geoff, mpe, rusty,
linux-kernel, paul.gortmaker, afleming, anton, srivatsa.bhat,
benh, paulus, ady8radu, linuxppc-dev
This patchset is a precursor for enabling deep idle states on powerpc,
when the local CPU timers stop. The tick broadcast framework in
the Linux Kernel today handles wakeup of such CPUs at their next timer event
by using an external clock device. At the expiry of this clock device, IPIs
are sent to the CPUs in deep idle states so that they wakeup to handle their
respective timers. This patchset frees up one of the IPI slots on powerpc
so as to be used to handle the tick broadcast IPI.
On certain implementations of powerpc, such an external clock device is absent.
Adding support to the tick broadcast framework to handle wakeup of CPUs from
deep idle states on such implementations is currently under discussion.
https://lkml.org/lkml/2014/1/15/86
https://lkml.org/lkml/2014/1/24/28
Either way this patchset is essential to enable handling the tick broadcast IPIs.
---
Preeti U Murthy (1):
cpuidle/ppc: Split timer_interrupt() into timer handling and interrupt handling routines
Srivatsa S. Bhat (2):
powerpc: Free up the slot of PPC_MSG_CALL_FUNC_SINGLE IPI message
powerpc: Implement tick broadcast IPI as a fixed IPI message
arch/powerpc/include/asm/smp.h | 2 -
arch/powerpc/include/asm/time.h | 1
arch/powerpc/kernel/smp.c | 23 ++++++--
arch/powerpc/kernel/time.c | 86 ++++++++++++++++++-------------
arch/powerpc/platforms/cell/interrupt.c | 2 -
arch/powerpc/platforms/ps3/smp.c | 2 -
6 files changed, 71 insertions(+), 45 deletions(-)
--
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox