[PATCH v4 3/3] powerpc: Enable HAVE_ARCH_SECCOMP_FILTER
Signed-off-by: Bogdan Purcareata bogdan.purcare...@freescale.com --- arch/powerpc/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 22b0940..2588b57 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -104,6 +104,7 @@ config PPC select HAVE_EFFICIENT_UNALIGNED_ACCESS if !CPU_LITTLE_ENDIAN select HAVE_KPROBES select HAVE_ARCH_KGDB + select HAVE_ARCH_SECCOMP_FILTER select HAVE_KRETPROBES select HAVE_ARCH_TRACEHOOK select HAVE_MEMBLOCK -- 2.1.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 1/3] powerpc: Don't force ENOSYS as error on syscall fail
In certain scenarios - e.g. seccomp filtering with ERRNO as default action -
the system call fails for other reasons than the syscall not being available.
The seccomp filter can be configured to store a user-defined error code on
return from a blacklisted syscall. Don't always set ENOSYS on
do_syscall_trace_enter failure.
Delegate setting ENOSYS in case of failure, where appropriate, to
do_syscall_trace_enter.
v4:
- update syscall_exit to be local label on 64bit, after rebasing on top of 3.19
v3:
- keep setting ENOSYS in the syscall entry assembly for scenarios without
syscall tracing
v2:
- move setting ENOSYS as errno from the syscall entry assembly to
do_syscall_trace_enter, only in the specific case
Signed-off-by: Bogdan Purcareata bogdan.purcare...@freescale.com
---
arch/powerpc/kernel/entry_32.S | 7 ++-
arch/powerpc/kernel/entry_64.S | 5 +++--
arch/powerpc/kernel/ptrace.c | 4 +++-
3 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 46fc0f4..b2f88cd 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -333,12 +333,12 @@ _GLOBAL(DoSyscall)
lwz r11,TI_FLAGS(r10)
andi. r11,r11,_TIF_SYSCALL_DOTRACE
bne-syscall_dotrace
-syscall_dotrace_cont:
cmplwi 0,r0,NR_syscalls
lis r10,sys_call_table@h
ori r10,r10,sys_call_table@l
slwir0,r0,2
bge-66f
+syscall_dotrace_cont:
lwzxr10,r10,r0 /* Fetch system call handler [ptr] */
mtlrr10
addir9,r1,STACK_FRAME_OVERHEAD
@@ -457,6 +457,11 @@ syscall_dotrace:
lwz r7,GPR7(r1)
lwz r8,GPR8(r1)
REST_NVGPRS(r1)
+ cmplwi 0,r0,NR_syscalls
+ lis r10,sys_call_table@h
+ ori r10,r10,sys_call_table@l
+ slwir0,r0,2
+ bge-ret_from_syscall
b syscall_dotrace_cont
syscall_exit_work:
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index d180caf2..5e7434e 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -144,7 +144,6 @@ END_FW_FTR_SECTION_IFSET(FW_FEATURE_SPLPAR)
ld r10,TI_FLAGS(r11)
andi. r11,r10,_TIF_SYSCALL_DOTRACE
bne syscall_dotrace
-.Lsyscall_dotrace_cont:
cmpldi 0,r0,NR_syscalls
bge-syscall_enosys
@@ -253,7 +252,9 @@ syscall_dotrace:
addir9,r1,STACK_FRAME_OVERHEAD
CURRENT_THREAD_INFO(r10, r1)
ld r10,TI_FLAGS(r10)
- b .Lsyscall_dotrace_cont
+ cmpldi 0,r0,NR_syscalls
+ bge-.Lsyscall_exit
+ b system_call
syscall_enosys:
li r3,-ENOSYS
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index f21897b..2edae06 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -1775,13 +1775,15 @@ long do_syscall_trace_enter(struct pt_regs *regs)
secure_computing_strict(regs-gpr[0]);
if (test_thread_flag(TIF_SYSCALL_TRACE)
- tracehook_report_syscall_entry(regs))
+ tracehook_report_syscall_entry(regs)) {
/*
* Tracing decided this syscall should not happen.
* We'll return a bogus call number to get an ENOSYS
* error, but leave the original number in regs-gpr[0].
*/
ret = -1L;
+ syscall_set_return_value(current, regs, ENOSYS, 0);
+ }
if (unlikely(test_thread_flag(TIF_SYSCALL_TRACEPOINT)))
trace_sys_enter(regs, regs-gpr[0]);
--
2.1.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 2/3] powerpc: Relax secure computing on syscall entry trace
The secure_computing_strict will just force the kernel to panic on
secure_computing failure. Once SECCOMP_FILTER support is enabled in the kernel,
syscalls can be denied without system failure.
v4:
- rebase on top of 3.19
v3,v2: no changes
Signed-off-by: Bogdan Purcareata bogdan.purcare...@freescale.com
---
arch/powerpc/kernel/ptrace.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 2edae06..cb9fd33 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -1772,7 +1772,9 @@ long do_syscall_trace_enter(struct pt_regs *regs)
user_exit();
- secure_computing_strict(regs-gpr[0]);
+ /* Do the secure computing check first; failures should be fast. */
+ if (secure_computing() == -1)
+ return -1L;
if (test_thread_flag(TIF_SYSCALL_TRACE)
tracehook_report_syscall_entry(regs)) {
--
2.1.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 0/3] powerpc: Enable seccomp filter support
Add the missing pieces in order to enable SECCOMP_FILTER on PowerPC architectures, and enable this support. Testing has been pursued using libseccomp with the latest ppc support patches [1][2], on Freescale platforms for both ppc and ppc64. Support on ppc64le has also been tested, courtesy of Mike Strosaker. [1] https://groups.google.com/forum/#!topic/libseccomp/oz42LfMDsxg [2] https://groups.google.com/forum/#!topic/libseccomp/TQWfCt_nD7c v4: - rebased on top of 3.19 v3: - keep setting ENOSYS in syscall entry assembly when syscall tracing is disabled v2: - move setting ENOSYS from syscall entry assembly to do_syscall_trace_enter Bogdan Purcareata (3): powerpc: Don't force ENOSYS as error on syscall fail powerpc: Relax secure computing on syscall entry trace powerpc: Enable HAVE_ARCH_SECCOMP_FILTER arch/powerpc/Kconfig | 1 + arch/powerpc/kernel/entry_32.S | 7 ++- arch/powerpc/kernel/entry_64.S | 5 +++-- arch/powerpc/kernel/ptrace.c | 8 ++-- 4 files changed, 16 insertions(+), 5 deletions(-) -- 2.1.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc/kvm: Limit MAX_VCPUS for guests running on RT Linux
Due to the introduction of the raw_spinlock for the KVM openpic, guests with a high number of VCPUs may induce great latencies on the underlying RT Linux system (e.g. cyclictest reports latencies of ~15ms for guests with 24 VCPUs). This can be further aggravated by sending a lot of external interrupts to the guest. A malicious app can abuse this scenario, causing a DoS of the host Linux. Until the KVM openpic code is refactored to use finer lock granularity, impose a limitation on the number of VCPUs a guest can have when running on a PREEMPT_RT_FULL system with KVM_MPIC emulation. Signed-off-by: Mihai Caraman mihai.cara...@freescale.com Signed-off-by: Bogdan Purcareata bogdan.purcare...@freescale.com Reviewed-by: Scott Wood scottw...@freescale.com --- arch/powerpc/include/asm/kvm_host.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h index 8ef0512..6f6b928 100644 --- a/arch/powerpc/include/asm/kvm_host.h +++ b/arch/powerpc/include/asm/kvm_host.h @@ -36,8 +36,14 @@ #include asm/cacheflush.h #include asm/hvcall.h +#if defined(CONFIG_PREEMPT_RT_FULL) defined(CONFIG_KVM_MPIC) +/* Limit the number of vcpus due to in-kernel mpic concurrency */ +#define KVM_MAX_VCPUS 4 +#define KVM_MAX_VCORES 4 +#else #define KVM_MAX_VCPUS NR_CPUS #define KVM_MAX_VCORES NR_CPUS +#endif #define KVM_USER_MEM_SLOTS 32 #define KVM_MEM_SLOTS_NUM KVM_USER_MEM_SLOTS -- 2.1.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc/kvm: Limit MAX_VCPUS for guests running on RT Linux
On 02/18/2015 10:32 AM, Bogdan Purcareata wrote: Due to the introduction of the raw_spinlock for the KVM openpic, guests with a high number of VCPUs may induce great latencies on the underlying RT Linux system (e.g. cyclictest reports latencies of ~15ms for guests with 24 VCPUs). This can be further aggravated by sending a lot of external interrupts to the guest. A malicious app can abuse this scenario, causing a DoS of the host Linux. Until the KVM openpic code is refactored to use finer lock granularity, impose a limitation on the number of VCPUs a guest can have when running on a PREEMPT_RT_FULL system with KVM_MPIC emulation. How is this possible? You take the raw lock, write a register, release the raw lock. How can the guest lockup the host? Is this write blocking in guest? Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] powerpc/kvm: Convert openpic lock to raw_spinlock
This patch enables running intensive I/O workloads, e.g. netperf, in a guest
deployed on a RT host. It also enable guests to be SMP.
The openpic spinlock becomes a sleeping mutex on a RT system. This no longer
guarantees that EPR is atomic with exception delivery. The guest VCPU thread
fails due to a BUG_ON(preemptible()) when running netperf.
In order to make the kvmppc_mpic_set_epr() call safe on RT from non-atomic
context, convert the openpic lock to a raw_spinlock. A similar approach can
be seen for x86 platforms in the following commit [1].
Here are some comparative cyclitest measurements run inside a high priority RT
guest run on a RT host. The guest has 1 VCPU and the test has been run for 15
minutes. The guest runs ~750 hackbench processes as background stress.
spinlock raw_spinlock
Min latency (us) 4 4
Avg latency (us) 1519
Max latency (us) 7062
[1] https://lkml.org/lkml/2010/1/11/289
Signed-off-by: Bogdan Purcareata bogdan.purcare...@freescale.com
Reviewed-by: Scott Wood scottw...@freescale.com
---
arch/powerpc/kvm/mpic.c | 44 ++--
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/kvm/mpic.c b/arch/powerpc/kvm/mpic.c
index 39b3a8f..9fad0aa 100644
--- a/arch/powerpc/kvm/mpic.c
+++ b/arch/powerpc/kvm/mpic.c
@@ -196,7 +196,7 @@ struct openpic {
int num_mmio_regions;
gpa_t reg_base;
- spinlock_t lock;
+ raw_spinlock_t lock;
/* Behavior control */
struct fsl_mpic_info *fsl;
@@ -1108,9 +1108,9 @@ static int openpic_cpu_write_internal(void *opaque, gpa_t
addr,
mpic_irq_raise(opp, dst, ILR_INTTGT_INT);
}
- spin_unlock(opp-lock);
+ raw_spin_unlock(opp-lock);
kvm_notify_acked_irq(opp-kvm, 0, notify_eoi);
- spin_lock(opp-lock);
+ raw_spin_lock(opp-lock);
break;
}
@@ -1185,12 +1185,12 @@ void kvmppc_mpic_set_epr(struct kvm_vcpu *vcpu)
int cpu = vcpu-arch.irq_cpu_id;
unsigned long flags;
- spin_lock_irqsave(opp-lock, flags);
+ raw_spin_lock_irqsave(opp-lock, flags);
if ((opp-gcr opp-mpic_mode_mask) == GCR_MODE_PROXY)
kvmppc_set_epr(vcpu, openpic_iack(opp, opp-dst[cpu], cpu));
- spin_unlock_irqrestore(opp-lock, flags);
+ raw_spin_unlock_irqrestore(opp-lock, flags);
}
static int openpic_cpu_read_internal(void *opaque, gpa_t addr,
@@ -1390,9 +1390,9 @@ static int kvm_mpic_read(struct kvm_io_device *this,
gpa_t addr,
return -EINVAL;
}
- spin_lock_irq(opp-lock);
+ raw_spin_lock_irq(opp-lock);
ret = kvm_mpic_read_internal(opp, addr - opp-reg_base, u.val);
- spin_unlock_irq(opp-lock);
+ raw_spin_unlock_irq(opp-lock);
/*
* Technically only 32-bit accesses are allowed, but be nice to
@@ -1430,10 +1430,10 @@ static int kvm_mpic_write(struct kvm_io_device *this,
gpa_t addr,
return -EOPNOTSUPP;
}
- spin_lock_irq(opp-lock);
+ raw_spin_lock_irq(opp-lock);
ret = kvm_mpic_write_internal(opp, addr - opp-reg_base,
*(const u32 *)ptr);
- spin_unlock_irq(opp-lock);
+ raw_spin_unlock_irq(opp-lock);
pr_debug(%s: addr %llx ret %d val %x\n,
__func__, addr, ret, *(const u32 *)ptr);
@@ -1504,14 +1504,14 @@ static int access_reg(struct openpic *opp, gpa_t addr,
u32 *val, int type)
if (addr 3)
return -ENXIO;
- spin_lock_irq(opp-lock);
+ raw_spin_lock_irq(opp-lock);
if (type == ATTR_SET)
ret = kvm_mpic_write_internal(opp, addr, *val);
else
ret = kvm_mpic_read_internal(opp, addr, val);
- spin_unlock_irq(opp-lock);
+ raw_spin_unlock_irq(opp-lock);
pr_debug(%s: type %d addr %llx val %x\n, __func__, type, addr, *val);
@@ -1548,9 +1548,9 @@ static int mpic_set_attr(struct kvm_device *dev, struct
kvm_device_attr *attr)
if (attr32 != 0 attr32 != 1)
return -EINVAL;
- spin_lock_irq(opp-lock);
+ raw_spin_lock_irq(opp-lock);
openpic_set_irq(opp, attr-attr, attr32);
- spin_unlock_irq(opp-lock);
+ raw_spin_unlock_irq(opp-lock);
return 0;
}
@@ -1595,9 +1595,9 @@ static int mpic_get_attr(struct kvm_device *dev, struct
kvm_device_attr *attr)
if (attr-attr MAX_SRC)
return -EINVAL;
- spin_lock_irq(opp-lock);
+ raw_spin_lock_irq(opp-lock);
attr32 = opp-src[attr-attr].pending;
- spin_unlock_irq(opp-lock);
+ raw_spin_unlock_irq(opp-lock);
if (put_user(attr32, (u32 __user *)(long)attr-addr))
[PATCH 0/2] powerpc/kvm: Enable running guests on RT Linux
This patchset enables running KVM SMP guests with external interrupts on an underlying RT-enabled Linux. Previous to this patch, a guest with in-kernel MPIC emulation could easily panic the kernel due to preemption when delivering IPIs and external interrupts, because of the openpic spinlock becoming a sleeping mutex on PREEMPT_RT_FULL Linux. 0001: converts the openpic spinlock to a raw spinlock, in order to circumvent this behavior. While this change is targeted for a RT enabled Linux, it has no effect on upstream kvm-ppc, so send it upstream for better future maintenance. 0002: introduces a limit on the maximum VCPUs a guest can have, in order to prevent potential DoS attack due to large system latencies. This patch is targeted to RT (due to CONFIG_PREEMPT_RT_FULL), but it can also be applied on upstream Linux, with no effect. Not sure if it's best to send it upstream and have a hanging CONFIG_PREEMPT_RT_FULL check there, with no effect, or send it against linux-stable-rt. Please apply as you consider appropriate. - applied compiled against upstream 3.19 - applied compiled against stable-rt 3.14-rt (0002 with minor fuzz) Bogdan Purcareata (2): powerpc/kvm: Convert openpic lock to raw_spinlock powerpc/kvm: Limit MAX_VCPUS for guests running on RT Linux arch/powerpc/include/asm/kvm_host.h | 6 + arch/powerpc/kvm/mpic.c | 44 ++--- 2 files changed, 28 insertions(+), 22 deletions(-) -- 2.1.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC v2 01/10] fsl_bman: Add drivers for the Freescale DPAA BMan
On Feb 16, 2015, at 9:46 AM, Emil Medve emilian.me...@freescale.com wrote: From: Geoff Thorpe geoff.tho...@freescale.com Change-Id: I075944acf740dbaae861104c17a9ff7247dec1be Signed-off-by: Geoff Thorpe geoff.tho...@freescale.com --- drivers/soc/Kconfig |1 + drivers/soc/Makefile |1 + drivers/soc/freescale/Kconfig| 51 ++ drivers/soc/freescale/Makefile |7 + drivers/soc/freescale/bman.c | 611 drivers/soc/freescale/bman.h | 524 + drivers/soc/freescale/bman_api.c | 1033 ++ drivers/soc/freescale/bman_portal.c | 330 +++ drivers/soc/freescale/bman_priv.h| 149 + drivers/soc/freescale/dpaa_alloc.c | 404 + drivers/soc/freescale/dpaa_sys.h | 235 drivers/soc/freescale/qbman_driver.c | 41 ++ include/linux/fsl_bman.h | 511 + If you are using drivers/soc than the include should probably be include/soc/freescale/ Also, any reason you guys aren’t using drivers/soc/fsl ? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC v2 01/10] fsl_bman: Add drivers for the Freescale DPAA BMan
Hello Kumar, Thanks for taking the time to review this On 02/18/2015 11:43 AM, Kumar Gala wrote: On Feb 16, 2015, at 9:46 AM, Emil Medve emilian.me...@freescale.com wrote: From: Geoff Thorpe geoff.tho...@freescale.com Change-Id: I075944acf740dbaae861104c17a9ff7247dec1be Signed-off-by: Geoff Thorpe geoff.tho...@freescale.com --- drivers/soc/Kconfig |1 + drivers/soc/Makefile |1 + drivers/soc/freescale/Kconfig| 51 ++ drivers/soc/freescale/Makefile |7 + drivers/soc/freescale/bman.c | 611 drivers/soc/freescale/bman.h | 524 + drivers/soc/freescale/bman_api.c | 1033 ++ drivers/soc/freescale/bman_portal.c | 330 +++ drivers/soc/freescale/bman_priv.h| 149 + drivers/soc/freescale/dpaa_alloc.c | 404 + drivers/soc/freescale/dpaa_sys.h | 235 drivers/soc/freescale/qbman_driver.c | 41 ++ include/linux/fsl_bman.h | 511 + If you are using drivers/soc than the include should probably be include/soc/freescale/ Will move/rename Also, any reason you guys aren’t using drivers/soc/fsl ? Will rename Cheers, ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH][v2] powerpc/mpc85xx: Add FMan platform support
From: Igal Liberman igal.liber...@freescale.com
Get the FMan devices/sub-nodes (MAC, MDIO, etc.) auto-probed
Signed-off-by: Igal Liberman igal.liber...@freescale.com
---
arch/powerpc/platforms/85xx/common.c |1 +
arch/powerpc/platforms/85xx/corenet_generic.c |3 +++
2 files changed, 4 insertions(+)
diff --git a/arch/powerpc/platforms/85xx/common.c
b/arch/powerpc/platforms/85xx/common.c
index a1cd3cc..958b3c6 100644
--- a/arch/powerpc/platforms/85xx/common.c
+++ b/arch/powerpc/platforms/85xx/common.c
@@ -42,6 +42,7 @@ static const struct of_device_id mpc85xx_common_ids[]
__initconst = {
{ .compatible = fsl,qoriq-pcie-v2.2, },
/* For the FMan driver */
{ .compatible = fsl,dpaa, },
+ { .compatible = fsl,fman, },
{},
};
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c
b/arch/powerpc/platforms/85xx/corenet_generic.c
index 9992e29..26b246d 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -124,6 +124,9 @@ static const struct of_device_id of_device_ids[] = {
{
.compatible = fsl,qe,
},
+ {
+ .compatible= fsl,fman,
+ },
/* The following two are for the Freescale hypervisor */
{
.name = hypervisor,
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC v2 00/10] Freescale DPAA B/QMan drivers
On Feb 16, 2015, at 9:46 AM, Emil Medve emilian.me...@freescale.com wrote: v2: Moved out of staging into soc/freescale Hello, This is the se attempt to publish the . They are not to be applied yet. These are the Freescale DPAA B/QMan drivers. At this stage, this is more or less the drivers from the Freescale PowerPC SDK roughly squashed and split in a sequence of component patches. They still needs some work and cleanup before we expect to have them applied, but we appreciate early feedback To do:Add a maintainer(s) entry Add module(s) support Some important clean-ups Cheers, Geoff Thorpe (8): fsl_bman: Add drivers for the Freescale DPAA BMan fsl_qman: Add drivers for the Freescale DPAA QMan powerpc/mpc85xx: Add platform support for the Freescale DPAA BMan powerpc/mpc85xx: Add platform support for the Freescale DPAA QMan fsl_bman: Add self-tester fsl_qman: Add self-tester fsl_bman: Add debugfs support fsl_qman: Add debugfs support Hai-Ying Wang (2): fsl_bman: Add HOTPLUG_CPU support fsl_qman: Add HOTPLUG_CPU support Really should look at using CMA for memory reservations used by q/bman backing store. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH][v3] powerpc/mpc85xx: Add FMan platform support
From: Igal Liberman igal.liber...@freescale.com
Get the FMan devices/sub-nodes (MAC, MDIO, etc.) auto-probed
Signed-off-by: Igal Liberman igal.liber...@freescale.com
---
arch/powerpc/platforms/85xx/common.c |1 +
arch/powerpc/platforms/85xx/corenet_generic.c |3 +++
2 files changed, 4 insertions(+)
diff --git a/arch/powerpc/platforms/85xx/common.c
b/arch/powerpc/platforms/85xx/common.c
index 4a9ad87..7bfb9b1 100644
--- a/arch/powerpc/platforms/85xx/common.c
+++ b/arch/powerpc/platforms/85xx/common.c
@@ -40,6 +40,7 @@ static const struct of_device_id mpc85xx_common_ids[]
__initconst = {
{ .compatible = fsl,qoriq-pcie-v2.4, },
{ .compatible = fsl,qoriq-pcie-v2.3, },
{ .compatible = fsl,qoriq-pcie-v2.2, },
+ { .compatible = fsl,fman, },
{},
};
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c
b/arch/powerpc/platforms/85xx/corenet_generic.c
index 63bef30..9824d2c 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -117,6 +117,9 @@ static const struct of_device_id of_device_ids[] = {
{
.compatible = fsl,qe,
},
+ {
+ .compatible= fsl,fman,
+ },
/* The following two are for the Freescale hypervisor */
{
.name = hypervisor,
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problems with Kernels 3.17-rc1 and onwards on Acube Sam460 AMCC 460ex board
On 2/15/2015 8:18 PM, Michael Ellerman wrote: On Sun, 2015-02-15 at 08:16 -0400, Julian Margetson wrote: Hi I am unable to get any kernel beyond the 3.16 branch working on an Acube Sam460ex AMCC 460ex based motherboard. Kernel up 3.16.7-ckt6 working. Does reverting b0345bbc6d09 change anything? [6.364350] snd_hda_intel 0001:81:00.1: enabling device ( - 0002) [6.453794] snd_hda_intel 0001:81:00.1: ppc4xx_setup_msi_irqs: fail mapping irq [6.487530] Unable to handle kernel paging request for data at address 0x0fa06c7c [6.495055] Faulting instruction address: 0xc032202c [6.500033] Vector: 300 (Data Access) at [efa31cf0] [6.504922] pc: c032202c: __reg_op+0xe8/0x100 [6.509697] lr: c0014f88: msi_bitmap_free_hwirqs+0x50/0x94 [6.515600] sp: efa31da0 [6.518491]msr: 21000 [6.521112]dar: fa06c7c [6.523915] dsisr: 0 [6.526190] current = 0xef8bab00 [6.529603] pid = 115, comm = kworker/0:1 [6.534163] enter ? for help [6.537054] [link register ] c0014f88 msi_bitmap_free_hwirqs+0x50/0x94 [6.543811] [efa31da0] c0014f78 msi_bitmap_free_hwirqs+0x40/0x94 (unreliable) [6.551001] [efa31dc0] c001aee8 ppc4xx_setup_msi_irqs+0xac/0xf4 [6.556973] [efa31e00] c03503a4 pci_enable_msi_range+0x1e0/0x280 [6.563032] [efa31e40] f92c2f74 azx_probe_work+0xe0/0x57c [snd_hda_intel] [6.569906] [efa31e80] c0036344 process_one_work+0x1e8/0x2f0 [6.575627] [efa31eb0] c003677c worker_thread+0x2f4/0x438 [6.581079] [efa31ef0] c003a3e4 kthread+0xc8/0xcc [6.585844] [efa31f40] c000aec4 ret_from_kernel_thread+0x5c/0x64 [6.591910] mon no input ... cheers Managed to do a third git bisect with the following results . git bisect bad 9279d3286e10736766edcaf815ae10e00856e448 is the first bad commit commit 9279d3286e10736766edcaf815ae10e00856e448 Author: Rasmus Villemoesli...@rasmusvillemoes.dk Date: Wed Aug 6 16:10:16 2014 -0700 lib: bitmap: change parameter of bitmap_*_region to unsigned Changing the pos parameter of __reg_op to unsigned allows the compiler to generate slightly smaller and simpler code. Also update its callers bitmap_*_region to receive and pass unsigned int. The return types of bitmap_find_free_region and bitmap_allocate_region are still int to allow a negative error code to be returned. An int is certainly capable of representing any realistic return value. Signed-off-by: Rasmus Villemoesli...@rasmusvillemoes.dk Signed-off-by: Andrew Mortona...@linux-foundation.org Signed-off-by: Linus Torvaldstorva...@linux-foundation.org :04 04 4f560a7caaba2d05c146a3cea27e0d93739d950c c3d4539acad26667a2d78844ead7b75af753f41e M include :04 04 7a6fb894aac2a1d4e72f8e36b7c6de3c24509ad3 31d756da185e07d2de090c9e6aeb12689d58d310 M lib ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] perf/e6500: Make event translations available in sysfs
Well I'm tired of discussing this. I don't think what you proposed makes sense, putting 3.4MB[1] of changing blob into perf. I'll resubmit the JSON parser without the downloader. Then users have the option to get their own events and use that. If you don't like that, standard perf just has to stay with limited events and r as before, with users having to use external tools or libraries for names for more events[2][3]. -Andi [1] Current size of https://download.01.org/perfmon/ [2] ocperf in https://github.com/andikleen/pmu-tools [3] http://perfmon2.sourceforge.net/ -- a...@linux.intel.com -- Speaking for myself only. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RESEND v2 7/7] PCI/hotplug: PowerPC PowerNV PCI hotplug driver
On Wed, 2015-02-18 at 08:30 -0600, Bjorn Helgaas wrote: So the hypervisor call that removes the device from the partition will fail if there are any translations that reference the memory of the device. Let me go through this in excruciating detail to see if I understand what's going on: - PCI core enumerates device D1 - PCI core sets device D1 BAR 0 = 0x1000 - driver claims D1 - driver ioremaps 0x1000 at virtual address V - translation V - 0x1000 is in TLB - driver iounmaps V (but V - 0x1000 translation may remain in TLB) - driver releases D1 - hot-remove D1 (without vm_unmap_aliases(), hypervisor would fail this) - it would be a bug to reference V here, but if we did, the virt-to-phys translation would succeed and we'd have a Master Abort or Unsupported Request on PCI/PCIe - hot-add D2 - PCI core enumerates device D2 - PCI core sets device D2 BAR 0 = 0x1000 - it would be a bug to reference V here (before ioremapping), but if we did, the reference would reach D2 I don't see anything hypervisor-specific here except for the fact that the hypervisor checks for existing translations and most other platforms don't. But it seems like the unexpected PCI aborts could happen on any platform. Well, only if we incorrectly dereferenced an ioremap'ed address for which the driver who owns it is long gone so fairly unlikely. I'm not saying you shouldn't put the vm_unmap_aliases() in the generic unplug code, I wouldn't mind that, but I don't think we have a nasty bug to squash here :) Are we saying that those PCI aborts are OK, since it's a bug to make those references in the first place? Or would we rather take a TLB miss fault instead so the references never make it to PCI? I think a miss fault which is basically a page fault - oops is preferable for debugging (after all that MMIO might hvae been reassigned to another device, so that abort might actually instead turn into writing to the wrong device... bad). However I also think the scenario is very unlikely. I would think there would be similar issues when unmapping and re-mapping plain old physical memory. But I don't see vm_unmap_aliases() calls there, so those issues must be handled differently. Should we handle this PCI hotplug issue the same way we handle RAM? If we don't have a vm_unmap_aliases() in the memory unplug path we probably have a bug on those HVs too :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] perf/e6500: Make event translations available in sysfs
* Scott Wood scottw...@freescale.com wrote: On Mon, 2015-02-09 at 21:40 +0100, Andi Kleen wrote: I'll NAK any external 'download area' (and I told that Andi before): tools/perf/event-tables/ or so is a good enough 'download area' with fast enough update cycles. The proposal was to put it on kernel.org, similar to how external firmware blobs are distributed. [...] Fortunately perf is not an external firmware blob ... [...] CPU event lists are data sheets, so are like firmware. [...] What an absolute, idiotic, nonsense argument! CPU event lists are human readable descriptions for events. If they aren't then they have no place in tooling. Treating them like firmware is as backwards as it gets. [...] They do not follow the normal kernel code licenses. They are not source code. They cannot be reviewed in the normal way. How is it different from describing registers and bits in driver header files? What does it mean to talk about a license on information, rather than the expression of information? Andi is making idiotic arguments, instead of implementing the technically sane solution. Thanks, Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problems with Kernels 3.17-rc1 and onwards on Acube Sam460 AMCC 460ex board
On 2/15/2015 8:18 PM, Michael Ellerman wrote: On Sun, 2015-02-15 at 08:16 -0400, Julian Margetson wrote: Hi I am unable to get any kernel beyond the 3.16 branch working on an Acube Sam460ex AMCC 460ex based motherboard. Kernel up 3.16.7-ckt6 working. Does reverting b0345bbc6d09 change anything? [6.364350] snd_hda_intel 0001:81:00.1: enabling device ( - 0002) [6.453794] snd_hda_intel 0001:81:00.1: ppc4xx_setup_msi_irqs: fail mapping irq [6.487530] Unable to handle kernel paging request for data at address 0x0fa06c7c [6.495055] Faulting instruction address: 0xc032202c [6.500033] Vector: 300 (Data Access) at [efa31cf0] [6.504922] pc: c032202c: __reg_op+0xe8/0x100 [6.509697] lr: c0014f88: msi_bitmap_free_hwirqs+0x50/0x94 [6.515600] sp: efa31da0 [6.518491]msr: 21000 [6.521112]dar: fa06c7c [6.523915] dsisr: 0 [6.526190] current = 0xef8bab00 [6.529603] pid = 115, comm = kworker/0:1 [6.534163] enter ? for help [6.537054] [link register ] c0014f88 msi_bitmap_free_hwirqs+0x50/0x94 [6.543811] [efa31da0] c0014f78 msi_bitmap_free_hwirqs+0x40/0x94 (unreliable) [6.551001] [efa31dc0] c001aee8 ppc4xx_setup_msi_irqs+0xac/0xf4 [6.556973] [efa31e00] c03503a4 pci_enable_msi_range+0x1e0/0x280 [6.563032] [efa31e40] f92c2f74 azx_probe_work+0xe0/0x57c [snd_hda_intel] [6.569906] [efa31e80] c0036344 process_one_work+0x1e8/0x2f0 [6.575627] [efa31eb0] c003677c worker_thread+0x2f4/0x438 [6.581079] [efa31ef0] c003a3e4 kthread+0xc8/0xcc [6.585844] [efa31f40] c000aec4 ret_from_kernel_thread+0x5c/0x64 [6.591910] mon no input ... cheers Managed to do a third git bisect with the following results . git bisect bad 9279d3286e10736766edcaf815ae10e00856e448 is the first bad commit commit 9279d3286e10736766edcaf815ae10e00856e448 Author: Rasmus Villemoes li...@rasmusvillemoes.dk Date: Wed Aug 6 16:10:16 2014 -0700 lib: bitmap: change parameter of bitmap_*_region to unsigned Changing the pos parameter of __reg_op to unsigned allows the compiler to generate slightly smaller and simpler code. Also update its callers bitmap_*_region to receive and pass unsigned int. The return types of bitmap_find_free_region and bitmap_allocate_region are still int to allow a negative error code to be returned. An int is certainly capable of representing any realistic return value. Signed-off-by: Rasmus Villemoes li...@rasmusvillemoes.dk Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Linus Torvalds torva...@linux-foundation.org :04 04 4f560a7caaba2d05c146a3cea27e0d93739d950c c3d4539acad26667a2d78844ead7b75af753f41e M include :04 04 7a6fb894aac2a1d4e72f8e36b7c6de3c24509ad3 31d756da185e07d2de090c9e6aeb12689d58d310 M lib ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RESEND PATCH] driver/cpuidle-powernv: Avoid endianness conversions while parsing DT
We currently read the information about idle states from the DT
so as to populate the cpuidle table. Use those APIs to read from
the DT that can avoid endianness conversions of the property values
in the cpuidle driver.
Signed-off-by: Preeti U Murthy pre...@linux.vnet.ibm.com
Acked-by: Michael Ellerman m...@ellerman.id.au
---
Based on top of linux-pm/linux-next
drivers/cpuidle/cpuidle-powernv.c | 29 -
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/drivers/cpuidle/cpuidle-powernv.c
b/drivers/cpuidle/cpuidle-powernv.c
index 30d4229..5937207 100644
--- a/drivers/cpuidle/cpuidle-powernv.c
+++ b/drivers/cpuidle/cpuidle-powernv.c
@@ -159,9 +159,7 @@ static int powernv_add_idle_states(void)
struct device_node *power_mgt;
int nr_idle_states = 1; /* Snooze */
int dt_idle_states;
- const __be32 *idle_state_flags;
- u32 len_flags, flags;
- u32 *latency_ns, *residency_ns;
+ u32 *latency_ns, *residency_ns, *flags;
int i, rc;
/* Currently we have snooze statically defined */
@@ -172,14 +170,19 @@ static int powernv_add_idle_states(void)
goto out;
}
- idle_state_flags = of_get_property(power_mgt,
- ibm,cpu-idle-state-flags, len_flags);
- if (!idle_state_flags) {
- pr_warn(cpuidle-powernv: missing ibm,cpu-idle-state-flags in
DT\n);
+ /* Read values of any property to determine the num of idle states */
+ dt_idle_states = of_property_count_u32_elems(power_mgt,
ibm,cpu-idle-state-flags);
+ if (dt_idle_states 0) {
+ pr_warn(cpuidle-powernv: no idle states found in the DT\n);
goto out;
}
- dt_idle_states = len_flags / sizeof(u32);
+ flags = kzalloc(sizeof(*flags) * dt_idle_states, GFP_KERNEL);
+ if (of_property_read_u32_array(power_mgt,
+ ibm,cpu-idle-state-flags, flags, dt_idle_states)) {
+ pr_warn(cpuidle-powernv : missing ibm,cpu-idle-state-flags in
DT\n);
+ goto out_free_flags;
+ }
latency_ns = kzalloc(sizeof(*latency_ns) * dt_idle_states, GFP_KERNEL);
rc = of_property_read_u32_array(power_mgt,
@@ -195,21 +198,19 @@ static int powernv_add_idle_states(void)
for (i = 0; i dt_idle_states; i++) {
- flags = be32_to_cpu(idle_state_flags[i]);
-
/*
* Cpuidle accepts exit_latency and target_residency in us.
* Use default target_residency values if f/w does not expose
it.
*/
- if (flags OPAL_PM_NAP_ENABLED) {
+ if (flags[i] OPAL_PM_NAP_ENABLED) {
/* Add NAP state */
strcpy(powernv_states[nr_idle_states].name, Nap);
strcpy(powernv_states[nr_idle_states].desc, Nap);
powernv_states[nr_idle_states].flags = 0;
powernv_states[nr_idle_states].target_residency = 100;
powernv_states[nr_idle_states].enter = nap_loop;
- } else if (flags OPAL_PM_SLEEP_ENABLED ||
- flags OPAL_PM_SLEEP_ENABLED_ER1) {
+ } else if (flags[i] OPAL_PM_SLEEP_ENABLED ||
+ flags[i] OPAL_PM_SLEEP_ENABLED_ER1) {
/* Add FASTSLEEP state */
strcpy(powernv_states[nr_idle_states].name,
FastSleep);
strcpy(powernv_states[nr_idle_states].desc,
FastSleep);
@@ -232,6 +233,8 @@ static int powernv_add_idle_states(void)
kfree(residency_ns);
out_free_latency:
kfree(latency_ns);
+out_free_flags:
+ kfree(flags);
out:
return nr_idle_states;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problems with Kernels 3.17-rc1 and onwards on Acube Sam460 AMCC 460ex board
On 2/18/2015 10:56 PM, Michael Ellerman wrote:
On Wed, 2015-02-18 at 21:36 -0400, Julian Margetson wrote:
On 2/18/2015 8:13 PM, Michael Ellerman wrote:
On Wed, 2015-02-18 at 15:45 -0400, Julian Margetson wrote:
On 2/15/2015 8:18 PM, Michael Ellerman wrote:
On Sun, 2015-02-15 at 08:16 -0400, Julian Margetson wrote:
Hi
I am unable to get any kernel beyond the 3.16 branch working on an
Acube Sam460ex
AMCC 460ex based motherboard. Kernel up 3.16.7-ckt6 working.
Does reverting b0345bbc6d09 change anything?
[6.364350] snd_hda_intel 0001:81:00.1: enabling device ( - 0002)
[6.453794] snd_hda_intel 0001:81:00.1: ppc4xx_setup_msi_irqs: fail mapping
irq
[6.487530] Unable to handle kernel paging request for data at address
0x0fa06c7c
[6.495055] Faulting instruction address: 0xc032202c
[6.500033] Vector: 300 (Data Access) at [efa31cf0]
[6.504922] pc: c032202c: __reg_op+0xe8/0x100
[6.509697] lr: c0014f88: msi_bitmap_free_hwirqs+0x50/0x94
[6.515600] sp: efa31da0
[6.518491]msr: 21000
[6.521112]dar: fa06c7c
[6.523915] dsisr: 0
[6.526190] current = 0xef8bab00
[6.529603] pid = 115, comm = kworker/0:1
[6.534163] enter ? for help
[6.537054] [link register ] c0014f88 msi_bitmap_free_hwirqs+0x50/0x94
[6.543811] [efa31da0] c0014f78 msi_bitmap_free_hwirqs+0x40/0x94 (unreliable)
[6.551001] [efa31dc0] c001aee8 ppc4xx_setup_msi_irqs+0xac/0xf4
[6.556973] [efa31e00] c03503a4 pci_enable_msi_range+0x1e0/0x280
[6.563032] [efa31e40] f92c2f74 azx_probe_work+0xe0/0x57c [snd_hda_intel]
[6.569906] [efa31e80] c0036344 process_one_work+0x1e8/0x2f0
[6.575627] [efa31eb0] c003677c worker_thread+0x2f4/0x438
[6.581079] [efa31ef0] c003a3e4 kthread+0xc8/0xcc
[6.585844] [efa31f40] c000aec4 ret_from_kernel_thread+0x5c/0x64
[6.591910] mon no input ...
Managed to do a third git bisect with the following results .
Great work.
git bisect bad
9279d3286e10736766edcaf815ae10e00856e448 is the first bad commit
commit 9279d3286e10736766edcaf815ae10e00856e448
Author: Rasmus Villemoes li...@rasmusvillemoes.dk
Date: Wed Aug 6 16:10:16 2014 -0700
lib: bitmap: change parameter of bitmap_*_region to unsigned
So the bug is in the 4xx MSI code, and has always been there, in fact I don't
see how that code has *ever* worked. The commit you bisected to just caused the
existing bug to cause an oops.
Can you try this?
diff --git a/arch/powerpc/sysdev/ppc4xx_msi.c b/arch/powerpc/sysdev/ppc4xx_msi.c
index 6e2e6aa378bb..effb5b878a78 100644
--- a/arch/powerpc/sysdev/ppc4xx_msi.c
+++ b/arch/powerpc/sysdev/ppc4xx_msi.c
@@ -95,11 +95,9 @@ static int ppc4xx_setup_msi_irqs(struct pci_dev *dev, int
nvec, int type)
list_for_each_entry(entry, dev-msi_list, list) {
int_no = msi_bitmap_alloc_hwirqs(msi_data-bitmap, 1);
- if (int_no = 0)
- break;
if (int_no 0) {
- pr_debug(%s: fail allocating msi interrupt\n,
- __func__);
+ pr_warn(%s: fail allocating msi interrupt\n,
__func__);
+ return -ENOSPC;
}
virq = irq_of_parse_and_map(msi_data-msi_dev, int_no);
if (virq == NO_IRQ) {
Thanks.
This works with 3.17-rc1. Will try with the 3.18 Branch .
OK great.
Any ideas why drm is not working ? (It never worked) .
No sorry. You might have more luck if you post a new thread to the dri list.
[5.809802] Linux agpgart interface v0.103
[6.137893] [drm] Initialized drm 1.1.0 20060810
[6.439872] snd_hda_intel 0001:81:00.1: enabling device ( - 0002)
[6.508544] ppc4xx_setup_msi_irqs: fail allocating msi interrupt
I'm curious why it's failing to allocate MSIs. Possibly it's just run out.
Can you post the output of 'cat /proc/interrupts'?
cheers
cat /proc/interrupts
CPU0
18: 0 UIC 11 Edge L2C
19: 0 UIC 12 Level snd_ice1724
20: 1 UIC 16 Level
21:306 UIC 17 Level snd_hda_intel
22: 12212 UIC 0 Level 0002:00:04.0
25:619 UIC 6 Level MAL TX EOB
26:937 UIC 7 Level MAL RX EOB
27: 0 UIC 3 Level MAL SERR
28: 0 UIC 4 Level MAL TX DE
31: 0 UIC 5 Level MAL RX DE
32: 6607 UIC 29 Level ehci_hcd:usb1
33: 1 UIC 30 Level ohci_hcd:usb2
38: 19 UIC 2 Level IBM IIC
39: 0 UIC 3 Level IBM IIC
40: 0 UIC 16 Level EMAC
44: 0 UIC 0 Edge aerdrv
45: 0 UIC 2 Edge aerdrv
LOC: 117318 Local timer interrupts for timer event device
LOC: 53 Local timer interrupts for others
SPU: 0 Spurious interrupts
PMI: 0 Performance
Re: [PATCH RESEND v2 7/7] PCI/hotplug: PowerPC PowerNV PCI hotplug driver
[+cc linux-mm, linux-kernel] For context, the start of this discussion was here: http://lkml.kernel.org/r/1424157203-691-8-git-send-email-gws...@linux.vnet.ibm.com where Gavin is adding a new PCI hotplug driver for PowerNV. That new driver calls vm_unmap_aliases() the same way we do in the existing RPA hotplug driver here: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/hotplug/rpaphp_core.c#n432 I'm trying to figure out whether it's correct to use vm_unmap_aliases() here, but I'm not an mm person so all I have is my gut feeling that something doesn't smell right. On Tue, Feb 17, 2015 at 6:30 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Wed, 2015-02-18 at 11:16 +1100, Gavin Shan wrote: What is vm_unmap_aliases() for? I see this is probably copied from rpaphp_core.c, where it was added by b4a26be9f6f8 (powerpc/pseries: Flush lazy kernel mappings after unplug operations). But I don't know whether: - this is something specific to powerpc, - the lack of vm_unmap_aliases() in other hotplug paths is a bug, - the fact that we only do this on powerpc is covering up a powerpc bug somewhere Yes, I copied this piece of code from rpaphp_core.c. I think Ben might help to answer the questions as he added the patch. I had very quick check on mm/vmalloc.c and it's reasonable to have vm_unmap_aliases() here to flush TLB entries for ioremap() regions, which were unmapped previously. if I'm correct. I don't think it's powerpc specific. It's specific to running under the PowerVM hypervisor, and thus doesn't affect PowerNV, just don't copy it over. It comes from the fact that the generic ioremap code nowadays delays TLB flushing on unmap. The TLB flushing code is what, on powerpc, ensures that we remove the translations from the MMU hash table (the hash table is essentially treated as an extended in-memory TLB), which on pseries turns into hypervisor calls. When running under that hypervisor, the HV ensures that no translation still exists in the hash before allowing a device to be removed from a partition. If translations still exist, the removal fails. So we need to force the generic ioremap code to perform all the TLB flushes for iounmap'ed regions before we complete the unplug operation from a kernel perspective so that the device can be re-assigned to another partition. This is thus useless on platforms like powernv which do not run under such a hypervisor. So the hypervisor call that removes the device from the partition will fail if there are any translations that reference the memory of the device. Let me go through this in excruciating detail to see if I understand what's going on: - PCI core enumerates device D1 - PCI core sets device D1 BAR 0 = 0x1000 - driver claims D1 - driver ioremaps 0x1000 at virtual address V - translation V - 0x1000 is in TLB - driver iounmaps V (but V - 0x1000 translation may remain in TLB) - driver releases D1 - hot-remove D1 (without vm_unmap_aliases(), hypervisor would fail this) - it would be a bug to reference V here, but if we did, the virt-to-phys translation would succeed and we'd have a Master Abort or Unsupported Request on PCI/PCIe - hot-add D2 - PCI core enumerates device D2 - PCI core sets device D2 BAR 0 = 0x1000 - it would be a bug to reference V here (before ioremapping), but if we did, the reference would reach D2 I don't see anything hypervisor-specific here except for the fact that the hypervisor checks for existing translations and most other platforms don't. But it seems like the unexpected PCI aborts could happen on any platform. Are we saying that those PCI aborts are OK, since it's a bug to make those references in the first place? Or would we rather take a TLB miss fault instead so the references never make it to PCI? I would think there would be similar issues when unmapping and re-mapping plain old physical memory. But I don't see vm_unmap_aliases() calls there, so those issues must be handled differently. Should we handle this PCI hotplug issue the same way we handle RAM? Bjorn ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/mpc85xx: Add FMan platform support
From: Igal Liberman igal.liber...@freescale.com
Get the FMan devices/sub-nodes (MAC, MDIO, etc.) auto-probed
Signed-off-by: Igal Liberman igal.liber...@freescale.com
Reviewed-on: http://git.am.freescale.net:8181/30408
Tested-by: Review Code-CDREVIEW cdrev...@freescale.com
Reviewed-by: Emilian Medve emilian.me...@freescale.com
---
arch/powerpc/platforms/85xx/common.c |1 +
arch/powerpc/platforms/85xx/corenet_generic.c |3 +++
2 files changed, 4 insertions(+)
diff --git a/arch/powerpc/platforms/85xx/common.c
b/arch/powerpc/platforms/85xx/common.c
index a1cd3cc..958b3c6 100644
--- a/arch/powerpc/platforms/85xx/common.c
+++ b/arch/powerpc/platforms/85xx/common.c
@@ -42,6 +42,7 @@ static const struct of_device_id mpc85xx_common_ids[]
__initconst = {
{ .compatible = fsl,qoriq-pcie-v2.2, },
/* For the FMan driver */
{ .compatible = fsl,dpaa, },
+ { .compatible = fsl,fman, },
{},
};
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c
b/arch/powerpc/platforms/85xx/corenet_generic.c
index 9992e29..26b246d 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -124,6 +124,9 @@ static const struct of_device_id of_device_ids[] = {
{
.compatible = fsl,qe,
},
+ {
+ .compatible= fsl,fman,
+ },
/* The following two are for the Freescale hypervisor */
{
.name = hypervisor,
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problems with Kernels 3.17-rc1 and onwards on Acube Sam460 AMCC 460ex board
On 2/18/2015 8:13 PM, Michael Ellerman wrote:
On Wed, 2015-02-18 at 15:45 -0400, Julian Margetson wrote:
On 2/15/2015 8:18 PM, Michael Ellerman wrote:
On Sun, 2015-02-15 at 08:16 -0400, Julian Margetson wrote:
Hi
I am unable to get any kernel beyond the 3.16 branch working on an
Acube Sam460ex
AMCC 460ex based motherboard. Kernel up 3.16.7-ckt6 working.
Does reverting b0345bbc6d09 change anything?
[6.364350] snd_hda_intel 0001:81:00.1: enabling device ( - 0002)
[6.453794] snd_hda_intel 0001:81:00.1: ppc4xx_setup_msi_irqs: fail mapping
irq
[6.487530] Unable to handle kernel paging request for data at address
0x0fa06c7c
[6.495055] Faulting instruction address: 0xc032202c
[6.500033] Vector: 300 (Data Access) at [efa31cf0]
[6.504922] pc: c032202c: __reg_op+0xe8/0x100
[6.509697] lr: c0014f88: msi_bitmap_free_hwirqs+0x50/0x94
[6.515600] sp: efa31da0
[6.518491]msr: 21000
[6.521112]dar: fa06c7c
[6.523915] dsisr: 0
[6.526190] current = 0xef8bab00
[6.529603] pid = 115, comm = kworker/0:1
[6.534163] enter ? for help
[6.537054] [link register ] c0014f88 msi_bitmap_free_hwirqs+0x50/0x94
[6.543811] [efa31da0] c0014f78 msi_bitmap_free_hwirqs+0x40/0x94 (unreliable)
[6.551001] [efa31dc0] c001aee8 ppc4xx_setup_msi_irqs+0xac/0xf4
[6.556973] [efa31e00] c03503a4 pci_enable_msi_range+0x1e0/0x280
[6.563032] [efa31e40] f92c2f74 azx_probe_work+0xe0/0x57c [snd_hda_intel]
[6.569906] [efa31e80] c0036344 process_one_work+0x1e8/0x2f0
[6.575627] [efa31eb0] c003677c worker_thread+0x2f4/0x438
[6.581079] [efa31ef0] c003a3e4 kthread+0xc8/0xcc
[6.585844] [efa31f40] c000aec4 ret_from_kernel_thread+0x5c/0x64
[6.591910] mon no input ...
Managed to do a third git bisect with the following results .
Great work.
git bisect bad
9279d3286e10736766edcaf815ae10e00856e448 is the first bad commit
commit 9279d3286e10736766edcaf815ae10e00856e448
Author: Rasmus Villemoes li...@rasmusvillemoes.dk
Date: Wed Aug 6 16:10:16 2014 -0700
lib: bitmap: change parameter of bitmap_*_region to unsigned
Changing the pos parameter of __reg_op to unsigned allows the compiler
to generate slightly smaller and simpler code. Also update its callers
bitmap_*_region to receive and pass unsigned int. The return types of
bitmap_find_free_region and bitmap_allocate_region are still int to
allow a negative error code to be returned. An int is certainly capable
of representing any realistic return value.
So that looks feasible as the culprit.
Looking at the 4xx MSI code, it just looks wrong:
static int ppc4xx_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
{
...
list_for_each_entry(entry, dev-msi_list, list) {
int_no = msi_bitmap_alloc_hwirqs(msi_data-bitmap, 1);
if (int_no = 0)
break;
That's backward, a *negative* return indicates an error.
if (int_no 0) {
pr_debug(%s: fail allocating msi interrupt\n,
__func__);
}
This is the correct check, but it just prints a warning and then continues,
which is not going to work.
virq = irq_of_parse_and_map(msi_data-msi_dev, int_no);
This will fail if int_no is negative.
if (virq == NO_IRQ) {
dev_err(dev-dev, %s: fail mapping irq\n, __func__);
msi_bitmap_free_hwirqs(msi_data-bitmap, int_no, 1);
And so here we can pass a negative int_no to the free routine, which then
oopses.
return -ENOSPC;
}
So the bug is in the 4xx MSI code, and has always been there, in fact I don't
see how that code has *ever* worked. The commit you bisected to just caused the
existing bug to cause an oops.
Can you try this?
diff --git a/arch/powerpc/sysdev/ppc4xx_msi.c b/arch/powerpc/sysdev/ppc4xx_msi.c
index 6e2e6aa378bb..effb5b878a78 100644
--- a/arch/powerpc/sysdev/ppc4xx_msi.c
+++ b/arch/powerpc/sysdev/ppc4xx_msi.c
@@ -95,11 +95,9 @@ static int ppc4xx_setup_msi_irqs(struct pci_dev *dev, int
nvec, int type)
list_for_each_entry(entry, dev-msi_list, list) {
int_no = msi_bitmap_alloc_hwirqs(msi_data-bitmap, 1);
- if (int_no = 0)
- break;
if (int_no 0) {
- pr_debug(%s: fail allocating msi interrupt\n,
- __func__);
+ pr_warn(%s: fail allocating msi interrupt\n,
__func__);
+ return -ENOSPC;
}
virq = irq_of_parse_and_map(msi_data-msi_dev, int_no);
if (virq == NO_IRQ) {
cheers
Thanks.
This works with 3.17-rc1. Will try with the 3.18 Branch .
Any ideas why drm is not working ? (It never worked) .
[5.809802] Linux agpgart interface
Re: [PATCH 4/4] powerpc/mpic: remove unused functions
On Mon, 2015-02-16 at 17:56 +0700, Arseny Solokha wrote: Drop unused fsl_mpic_primary_get_version(), mpic_set_clk_ratio(), mpic_set_serial_int(). I'm always happy to remove unused code, but the interesting question is why are they unused? Please tell me in the changelog. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problems with Kernels 3.17-rc1 and onwards on Acube Sam460 AMCC 460ex board
On Wed, 2015-02-18 at 21:36 -0400, Julian Margetson wrote:
On 2/18/2015 8:13 PM, Michael Ellerman wrote:
On Wed, 2015-02-18 at 15:45 -0400, Julian Margetson wrote:
On 2/15/2015 8:18 PM, Michael Ellerman wrote:
On Sun, 2015-02-15 at 08:16 -0400, Julian Margetson wrote:
Hi
I am unable to get any kernel beyond the 3.16 branch working on an
Acube Sam460ex
AMCC 460ex based motherboard. Kernel up 3.16.7-ckt6 working.
Does reverting b0345bbc6d09 change anything?
[6.364350] snd_hda_intel 0001:81:00.1: enabling device ( -
0002)
[6.453794] snd_hda_intel 0001:81:00.1: ppc4xx_setup_msi_irqs:
fail mapping irq
[6.487530] Unable to handle kernel paging request for data at
address 0x0fa06c7c
[6.495055] Faulting instruction address: 0xc032202c
[6.500033] Vector: 300 (Data Access) at [efa31cf0]
[6.504922] pc: c032202c: __reg_op+0xe8/0x100
[6.509697] lr: c0014f88: msi_bitmap_free_hwirqs+0x50/0x94
[6.515600] sp: efa31da0
[6.518491]msr: 21000
[6.521112]dar: fa06c7c
[6.523915] dsisr: 0
[6.526190] current = 0xef8bab00
[6.529603] pid = 115, comm = kworker/0:1
[6.534163] enter ? for help
[6.537054] [link register ] c0014f88
msi_bitmap_free_hwirqs+0x50/0x94
[6.543811] [efa31da0] c0014f78 msi_bitmap_free_hwirqs+0x40/0x94
(unreliable)
[6.551001] [efa31dc0] c001aee8 ppc4xx_setup_msi_irqs+0xac/0xf4
[6.556973] [efa31e00] c03503a4 pci_enable_msi_range+0x1e0/0x280
[6.563032] [efa31e40] f92c2f74 azx_probe_work+0xe0/0x57c
[snd_hda_intel]
[6.569906] [efa31e80] c0036344 process_one_work+0x1e8/0x2f0
[6.575627] [efa31eb0] c003677c worker_thread+0x2f4/0x438
[6.581079] [efa31ef0] c003a3e4 kthread+0xc8/0xcc
[6.585844] [efa31f40] c000aec4 ret_from_kernel_thread+0x5c/0x64
[6.591910] mon no input ...
Managed to do a third git bisect with the following results .
Great work.
git bisect bad
9279d3286e10736766edcaf815ae10e00856e448 is the first bad commit
commit 9279d3286e10736766edcaf815ae10e00856e448
Author: Rasmus Villemoes li...@rasmusvillemoes.dk
Date: Wed Aug 6 16:10:16 2014 -0700
lib: bitmap: change parameter of bitmap_*_region to unsigned
So the bug is in the 4xx MSI code, and has always been there, in fact I
don't
see how that code has *ever* worked. The commit you bisected to just caused
the
existing bug to cause an oops.
Can you try this?
diff --git a/arch/powerpc/sysdev/ppc4xx_msi.c
b/arch/powerpc/sysdev/ppc4xx_msi.c
index 6e2e6aa378bb..effb5b878a78 100644
--- a/arch/powerpc/sysdev/ppc4xx_msi.c
+++ b/arch/powerpc/sysdev/ppc4xx_msi.c
@@ -95,11 +95,9 @@ static int ppc4xx_setup_msi_irqs(struct pci_dev *dev,
int nvec, int type)
list_for_each_entry(entry, dev-msi_list, list) {
int_no = msi_bitmap_alloc_hwirqs(msi_data-bitmap, 1);
- if (int_no = 0)
- break;
if (int_no 0) {
- pr_debug(%s: fail allocating msi interrupt\n,
- __func__);
+ pr_warn(%s: fail allocating msi interrupt\n,
__func__);
+ return -ENOSPC;
}
virq = irq_of_parse_and_map(msi_data-msi_dev, int_no);
if (virq == NO_IRQ) {
Thanks.
This works with 3.17-rc1. Will try with the 3.18 Branch .
OK great.
Any ideas why drm is not working ? (It never worked) .
No sorry. You might have more luck if you post a new thread to the dri list.
[5.809802] Linux agpgart interface v0.103
[6.137893] [drm] Initialized drm 1.1.0 20060810
[6.439872] snd_hda_intel 0001:81:00.1: enabling device ( - 0002)
[6.508544] ppc4xx_setup_msi_irqs: fail allocating msi interrupt
I'm curious why it's failing to allocate MSIs. Possibly it's just run out.
Can you post the output of 'cat /proc/interrupts'?
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: driver/cpuidle-powernv: Avoid endianness conversions while parsing DT
On Tue, 2015-03-02 at 06:31:15 UTC, Preeti U Murthy wrote: We currently read the information about idle states from the DT so as to populate the cpuidle table. Use those APIs to read from the DT that can avoid endianness conversions of the property values in the cpuidle driver. Signed-off-by: Preeti U Murthy pre...@linux.vnet.ibm.com Acked-by: Michael Ellerman m...@ellerman.id.au cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problems with Kernels 3.17-rc1 and onwards on Acube Sam460 AMCC 460ex board
On Wed, 2015-02-18 at 15:45 -0400, Julian Margetson wrote:
On 2/15/2015 8:18 PM, Michael Ellerman wrote:
On Sun, 2015-02-15 at 08:16 -0400, Julian Margetson wrote:
Hi
I am unable to get any kernel beyond the 3.16 branch working on an
Acube Sam460ex
AMCC 460ex based motherboard. Kernel up 3.16.7-ckt6 working.
Does reverting b0345bbc6d09 change anything?
[6.364350] snd_hda_intel 0001:81:00.1: enabling device ( - 0002)
[6.453794] snd_hda_intel 0001:81:00.1: ppc4xx_setup_msi_irqs: fail
mapping irq
[6.487530] Unable to handle kernel paging request for data at address
0x0fa06c7c
[6.495055] Faulting instruction address: 0xc032202c
[6.500033] Vector: 300 (Data Access) at [efa31cf0]
[6.504922] pc: c032202c: __reg_op+0xe8/0x100
[6.509697] lr: c0014f88: msi_bitmap_free_hwirqs+0x50/0x94
[6.515600] sp: efa31da0
[6.518491]msr: 21000
[6.521112]dar: fa06c7c
[6.523915] dsisr: 0
[6.526190] current = 0xef8bab00
[6.529603] pid = 115, comm = kworker/0:1
[6.534163] enter ? for help
[6.537054] [link register ] c0014f88
msi_bitmap_free_hwirqs+0x50/0x94
[6.543811] [efa31da0] c0014f78 msi_bitmap_free_hwirqs+0x40/0x94
(unreliable)
[6.551001] [efa31dc0] c001aee8 ppc4xx_setup_msi_irqs+0xac/0xf4
[6.556973] [efa31e00] c03503a4 pci_enable_msi_range+0x1e0/0x280
[6.563032] [efa31e40] f92c2f74 azx_probe_work+0xe0/0x57c
[snd_hda_intel]
[6.569906] [efa31e80] c0036344 process_one_work+0x1e8/0x2f0
[6.575627] [efa31eb0] c003677c worker_thread+0x2f4/0x438
[6.581079] [efa31ef0] c003a3e4 kthread+0xc8/0xcc
[6.585844] [efa31f40] c000aec4 ret_from_kernel_thread+0x5c/0x64
[6.591910] mon no input ...
Managed to do a third git bisect with the following results .
Great work.
git bisect bad
9279d3286e10736766edcaf815ae10e00856e448 is the first bad commit
commit 9279d3286e10736766edcaf815ae10e00856e448
Author: Rasmus Villemoes li...@rasmusvillemoes.dk
Date: Wed Aug 6 16:10:16 2014 -0700
lib: bitmap: change parameter of bitmap_*_region to unsigned
Changing the pos parameter of __reg_op to unsigned allows the compiler
to generate slightly smaller and simpler code. Also update its callers
bitmap_*_region to receive and pass unsigned int. The return types of
bitmap_find_free_region and bitmap_allocate_region are still int to
allow a negative error code to be returned. An int is certainly capable
of representing any realistic return value.
So that looks feasible as the culprit.
Looking at the 4xx MSI code, it just looks wrong:
static int ppc4xx_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
{
...
list_for_each_entry(entry, dev-msi_list, list) {
int_no = msi_bitmap_alloc_hwirqs(msi_data-bitmap, 1);
if (int_no = 0)
break;
That's backward, a *negative* return indicates an error.
if (int_no 0) {
pr_debug(%s: fail allocating msi interrupt\n,
__func__);
}
This is the correct check, but it just prints a warning and then continues,
which is not going to work.
virq = irq_of_parse_and_map(msi_data-msi_dev, int_no);
This will fail if int_no is negative.
if (virq == NO_IRQ) {
dev_err(dev-dev, %s: fail mapping irq\n, __func__);
msi_bitmap_free_hwirqs(msi_data-bitmap, int_no, 1);
And so here we can pass a negative int_no to the free routine, which then
oopses.
return -ENOSPC;
}
So the bug is in the 4xx MSI code, and has always been there, in fact I don't
see how that code has *ever* worked. The commit you bisected to just caused the
existing bug to cause an oops.
Can you try this?
diff --git a/arch/powerpc/sysdev/ppc4xx_msi.c b/arch/powerpc/sysdev/ppc4xx_msi.c
index 6e2e6aa378bb..effb5b878a78 100644
--- a/arch/powerpc/sysdev/ppc4xx_msi.c
+++ b/arch/powerpc/sysdev/ppc4xx_msi.c
@@ -95,11 +95,9 @@ static int ppc4xx_setup_msi_irqs(struct pci_dev *dev, int
nvec, int type)
list_for_each_entry(entry, dev-msi_list, list) {
int_no = msi_bitmap_alloc_hwirqs(msi_data-bitmap, 1);
- if (int_no = 0)
- break;
if (int_no 0) {
- pr_debug(%s: fail allocating msi interrupt\n,
- __func__);
+ pr_warn(%s: fail allocating msi interrupt\n,
__func__);
+ return -ENOSPC;
}
virq = irq_of_parse_and_map(msi_data-msi_dev, int_no);
if (virq == NO_IRQ) {
cheers
___
Linuxppc-dev mailing list
Re: [PATCH 0/3] powerpc/powernv: Correctly detect optional OPAL calls
Vasant Hegde hegdevas...@linux.vnet.ibm.com writes: On 02/18/2015 05:33 AM, Stewart Smith wrote: This series fixes three possible warnings that OPAL firmware would emit when booting on hardware/simulator that didn't support certain functionality. The correct thing for Linux to do is to detect firmware capability by using the OPAL_CHECK_TOKEN call or examining device tree. In the case of these three warnings, it was OPAL_CHECK_TOKEN. Stewart, Sorry.. I couldn't makeout any difference between this patchset and earlier patchset which I had Acked except the update in cover page... (sub: Silence OPAL called with invalid token errors ). Did I miss anything ? You missed that I forgot I'd sent the patchset. :) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problems with Kernels 3.17-rc1 and onwards on Acube Sam460 AMCC 460ex board
On Wed, 2015-02-18 at 15:45 -0400, Julian Margetson wrote:
On 2/15/2015 8:18 PM, Michael Ellerman wrote:
On Sun, 2015-02-15 at 08:16 -0400, Julian Margetson wrote:
Hi
I am unable to get any kernel beyond the 3.16 branch working on an
Acube Sam460ex
AMCC 460ex based motherboard. Kernel up 3.16.7-ckt6 working.
Does reverting b0345bbc6d09 change anything?
[6.364350] snd_hda_intel 0001:81:00.1: enabling device ( - 0002)
[6.453794] snd_hda_intel 0001:81:00.1: ppc4xx_setup_msi_irqs: fail
mapping irq
[6.487530] Unable to handle kernel paging request for data at address
0x0fa06c7c
[6.495055] Faulting instruction address: 0xc032202c
[6.500033] Vector: 300 (Data Access) at [efa31cf0]
[6.504922] pc: c032202c: __reg_op+0xe8/0x100
[6.509697] lr: c0014f88: msi_bitmap_free_hwirqs+0x50/0x94
[6.515600] sp: efa31da0
[6.518491]msr: 21000
[6.521112]dar: fa06c7c
[6.523915] dsisr: 0
[6.526190] current = 0xef8bab00
[6.529603] pid = 115, comm = kworker/0:1
[6.534163] enter ? for help
[6.537054] [link register ] c0014f88 msi_bitmap_free_hwirqs+0x50/0x94
[6.543811] [efa31da0] c0014f78 msi_bitmap_free_hwirqs+0x40/0x94
(unreliable)
[6.551001] [efa31dc0] c001aee8 ppc4xx_setup_msi_irqs+0xac/0xf4
[6.556973] [efa31e00] c03503a4 pci_enable_msi_range+0x1e0/0x280
[6.563032] [efa31e40] f92c2f74 azx_probe_work+0xe0/0x57c [snd_hda_intel]
[6.569906] [efa31e80] c0036344 process_one_work+0x1e8/0x2f0
[6.575627] [efa31eb0] c003677c worker_thread+0x2f4/0x438
[6.581079] [efa31ef0] c003a3e4 kthread+0xc8/0xcc
[6.585844] [efa31f40] c000aec4 ret_from_kernel_thread+0x5c/0x64
[6.591910] mon no input ...
Managed to do a third git bisect with the following results .
Great work.
git bisect bad
9279d3286e10736766edcaf815ae10e00856e448 is the first bad commit
commit 9279d3286e10736766edcaf815ae10e00856e448
Author: Rasmus Villemoes li...@rasmusvillemoes.dk
Date: Wed Aug 6 16:10:16 2014 -0700
lib: bitmap: change parameter of bitmap_*_region to unsigned
Changing the pos parameter of __reg_op to unsigned allows the compiler
to generate slightly smaller and simpler code. Also update its callers
bitmap_*_region to receive and pass unsigned int. The return types of
bitmap_find_free_region and bitmap_allocate_region are still int to
allow a negative error code to be returned. An int is certainly capable
of representing any realistic return value.
So that looks feasible as the culprit.
Looking at the 4xx MSI code, it just looks wrong:
static int ppc4xx_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
{
...
list_for_each_entry(entry, dev-msi_list, list) {
int_no = msi_bitmap_alloc_hwirqs(msi_data-bitmap, 1);
if (int_no = 0)
break;
That's backward, a *negative* return indicates an error.
if (int_no 0) {
pr_debug(%s: fail allocating msi interrupt\n,
__func__);
}
This is the correct check, but it just prints a warning and then continues,
which is not going to work.
virq = irq_of_parse_and_map(msi_data-msi_dev, int_no);
This will fail if int_no is negative.
if (virq == NO_IRQ) {
dev_err(dev-dev, %s: fail mapping irq\n, __func__);
msi_bitmap_free_hwirqs(msi_data-bitmap, int_no, 1);
And so here we can pass a negative int_no to the free routine, which
then oopses.
return -ENOSPC;
}
So the bug is in the 4xx MSI code, and has always been there, in fact I
don't
see how that code has *ever* worked. The commit you bisected to just
caused the
existing bug to cause an oops.
Can you try this?
diff --git a/arch/powerpc/sysdev/ppc4xx_msi.c
b/arch/powerpc/sysdev/ppc4xx_msi.c
index 6e2e6aa378bb..effb5b878a78 100644
--- a/arch/powerpc/sysdev/ppc4xx_msi.c
+++ b/arch/powerpc/sysdev/ppc4xx_msi.c
@@ -95,11 +95,9 @@ static int ppc4xx_setup_msi_irqs(struct pci_dev *dev,
int nvec, int type)
list_for_each_entry(entry, dev-msi_list, list) {
int_no = msi_bitmap_alloc_hwirqs(msi_data-bitmap, 1);
- if (int_no = 0)
- break;
if (int_no 0) {
- pr_debug(%s: fail allocating msi interrupt\n,
- __func__);
+ pr_warn(%s: fail allocating msi interrupt\n,
__func__);
+ return -ENOSPC;
}
virq = irq_of_parse_and_map(msi_data-msi_dev, int_no);
if (virq == NO_IRQ) {
cheers
Can also confirm patch working with kernel 3.18.7 .
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
