[PATCH] powerpc/mpic: fix irq distribution problem when MPIC_SINGLE_DEST_CPU
For the mpic with a flag MPIC_SINGLE_DEST_CPU, only one bit should be
set in interrupt destination registers.
The code is applicable to 64-bit platforms as well as 32-bit.
Signed-off-by: Zhao Chenhui
---
arch/powerpc/sysdev/mpic.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 0a13ecb..3cc2f91 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -54,7 +54,7 @@ static DEFINE_RAW_SPINLOCK(mpic_lock);
#ifdef CONFIG_PPC32/* XXX for now */
#ifdef CONFIG_IRQ_ALL_CPUS
-#define distribute_irqs(!(mpic->flags & MPIC_SINGLE_DEST_CPU))
+#define distribute_irqs(1)
#else
#define distribute_irqs(0)
#endif
@@ -1703,7 +1703,7 @@ void mpic_setup_this_cpu(void)
* it differently, then we should make sure we also change the default
* values of irq_desc[].affinity in irq.c.
*/
- if (distribute_irqs) {
+ if (distribute_irqs && !(mpic->flags & MPIC_SINGLE_DEST_CPU)) {
for (i = 0; i < mpic->num_sources ; i++)
mpic_irq_write(i, MPIC_INFO(IRQ_DESTINATION),
mpic_irq_read(i, MPIC_INFO(IRQ_DESTINATION)) |
msk);
--
1.7.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/sysfs: disable hotplug for the boot cpu
Some features depend on the boot cpu, for instance, hibernate/suspend.
So disable hotplug for the boot cpu.
Signed-off-by: Zhao Chenhui
---
arch/powerpc/kernel/sysfs.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index e68a845..294b1c4e 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -655,8 +655,10 @@ static int __init topology_init(void)
* CPU. For instance, the boot cpu might never be valid
* for hotplugging.
*/
- if (ppc_md.cpu_die)
+ if (ppc_md.cpu_die && cpu != boot_cpuid)
c->hotpluggable = 1;
+ else
+ c->hotpluggable = 0;
if (cpu_online(cpu) || c->hotpluggable) {
register_cpu(c, cpu);
--
1.7.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.
* Russell King - ARM Linux wrote: > So, if you want to use this, then you should update the CONFIG_BUG text > to include a warning to this effect: > > Warning: if CONFIG_BUG is turned off, and control flow reaches > a BUG(), the system behaviour will be undefined. > > so that people can make an informed choice about this, because at the > moment: > > Disabling this option eliminates support for BUG and WARN, reducing > the size of your kernel image and potentially quietly ignoring > numerous fatal conditions. You should only consider disabling this > option for embedded systems with no facilities for reporting errors. > Just say Y. > > will become completely misleading. Turning this option off will _not_ > result in "quietly ignoring numerous fatal conditions". I'm fine with adding your text as a clarification - but I think 'quietly ignoring fatal conditions' very much implies an undefined outcome if that unexpected condition does occur: the code might crash, it might corrupt memory or it might do some other unexpected thing. There are many other places that do a BUG_ON() of a NULL pointer or so, or of a zero refcount, or a not held lock - and turning the BUG_ON() off makes the code unpredictable _anyway_ - even if the compiler does not notice an uninitialized variable. So pretty much any weakening of BUG_ON() _will_ make the kernel more unpredictable. > And I come back to one of my previous arguments - is it not better to > panic() if we hit one of these conditions so that the system can try to > do a panic-reboot rather than continue blindly into the unknown? It will often continue blindly into the unknown even if the compiler is happy ... The only difference is that it's "unpredictable" in a way not visible from the C code: the code won't necessarily fall through the BUG() when hitting that condition - although in practice it probably will. So I think the same principle applies to it as to any other debugging code: it's fine to be able to turn debugging off. It's a performance versus kernel robustness/determinism trade-off. Thanks, Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.
On 05/28/2013 04:19 PM, Ingo Molnar wrote: >> > And I come back to one of my previous arguments - is it not better to >> > panic() if we hit one of these conditions so that the system can try to >> > do a panic-reboot rather than continue blindly into the unknown? > It will often continue blindly into the unknown even if the compiler is > happy ... > For Server, it is necessary to always enable CONFIG_BUG and call panic() When analyzing core dump or KDB trap, we have to assume that the kernel has already "continued blindly", but lucky, we can get the core dump or KDB trap finally (sometimes, we really even can not get core dump or KDB trap). For PC, it is useless to disable CONFIG_BUG The PC memory has already large enough to skip the minimal size optimization. And its speed is also high enough to skip the speed improvement by minimal size optimization. For Embedded system, some of architectures may disable CONFIG_BUG. Embedded system are widely used in many area, so the requirement of each architectures for BUG() may be different, some may need reboot as quickly as possible for urgent processing; some may need dead looping in BUG() for avoid user amazing; (if auto-reboot, users feel out of control, don't know what happens) some may still need panic() just like Server requirements. others may not care about it, just implement it as minimal size. > The only difference is that i t's "unpredictable" in a way not visible from > the C code: the code won't necessarily fall through the BUG() when hitting > that condition - although in practice it probably will. > > So I think the same principle applies to it as to any other debugging > code: it's fine to be able to turn debugging off. It's a performance > versus kernel robustness/determinism trade-off. 'minimal size' for BUG() is belongs to some of Embedded system specific features, it is not 'generic' enough to be in "include/asm-generic/". If we still provide the "disable CONFIG_BUG", some of 'crazy users' (e.g. randconfig) may make 'noise' to most of architectures. So we need not provide "disable CONFIG_BUG" features for all platforms, since most of architectures need not support it, and the architecture which really need minimal size, can implement it by itself as a architecture specific feature. Thanks. -- Chen Gang Asianux Corporation ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.
On Tuesday 28 May 2013 10:19:10 Ingo Molnar wrote:
>
> * Russell King - ARM Linux wrote:
>
> > So, if you want to use this, then you should update the CONFIG_BUG text
> > to include a warning to this effect:
> >
> > Warning: if CONFIG_BUG is turned off, and control flow reaches
> > a BUG(), the system behaviour will be undefined.
> >
> > so that people can make an informed choice about this, because at the
> > moment:
> >
> > Disabling this option eliminates support for BUG and WARN,
> > reducing
> > the size of your kernel image and potentially quietly ignoring
> > numerous fatal conditions. You should only consider disabling this
> > option for embedded systems with no facilities for reporting
> > errors.
> > Just say Y.
> >
> > will become completely misleading. Turning this option off will _not_
> > result in "quietly ignoring numerous fatal conditions".
>
> I'm fine with adding your text as a clarification - but I think 'quietly
> ignoring fatal conditions' very much implies an undefined outcome if that
> unexpected condition does occur: the code might crash, it might corrupt
> memory or it might do some other unexpected thing.
>
> There are many other places that do a BUG_ON() of a NULL pointer or so, or
> of a zero refcount, or a not held lock - and turning the BUG_ON() off
> makes the code unpredictable _anyway_ - even if the compiler does not
> notice an uninitialized variable.
>
> So pretty much any weakening of BUG_ON() _will_ make the kernel more
> unpredictable.
FWIW, I've run some size analyis using the ARM 'multi_v7_defconfig'
and gcc-4.8, using various definitions for BUG() and BUG_ON(), to
see how big the size improvement actually gets
1. Baseline: normal bug plus CONFIG_BUG_VERBOSE
textdata bss dec hex filename
3743196 224396 206812 4174404 3fb244 vmlinux-bugverbose
2. disabling CONFIG_BUG_VERBOSE, saving 0.6%
3716920 224380 206812 4148112 3f4b90 vmlinux-nobugverbose
3. #define BUG() panic(__func__), #define BUG_ON(c) if(c) BUG(), saving 1.0%
3701076 224384 206812 4132272 3f0db0 vmlinux-bug-panicfunc
3. #define BUG() panic(__func__), #define BUG_ON(c) if(c) BUG(), saving 1.5%
3678884 224400 206812 4110096 3eb710 vmlinux-bug-panic
4. #define BUG() unreachable(), saving 2.1%
3652636 224384 206812 4083832 3e5078 vmlinux-bug-unreachable
5. as 4, plus #define BUG_ON(c) if(c) unreachable(), saving 2.2%
3651108 224380 206812 4082300 3e4a7c vmlinux-bugon-unreachable
6. #define BUG() do{}while(0), saving 2.1%
3654264 224380 206812 4085456 3e56d0 vmlinux-nobug
7. as 6, plus #define BUG_ON if(0 && (c)) unreachable, saving 2.2%
3648392 223996 206748 4079136 3e3e20 vmlinux-no-bugon
8. my patch below, saving 1.8%
3666532 224380 206812 4097724 3e86bc obj-tmp/vmlinux
The gain of doing unreachable and letting the code run off whereever
is minimal compared to the current state of doing nothing, but it
avoids the warnings.
Same test using x86_defconfig:
1. CONFIG_BUG=y, CONFIG_BUGVERBOSE=n
107978591395648 1175552 13369059 cbfee3 vmlinux-x86-bug
2. CONFIG_BUG=n, saves 1.0%
106585531395584 1175552 13229689 c9de79 vmlinux-x86-nobug
3. with my patch, saves 0.8%
106841861395584 1175552 13255322 ca429a vmlinux-x86-archbug
Getting 1-2% savings in kernel size seems absolutely worth keeping the
option, but 0.2-0.4% left for getting reproducible behavior also seems
worthwhile. The result in the patch below.
This basically loses any of the BUG() reporting, but leaves the
logic to trap and kill the task in place when CONFIG_BUG is disabled.
Signed-off-by: Arnd Bergmann
diff --git a/arch/arm/include/asm/bug.h b/arch/arm/include/asm/bug.h
index 7af5c6c..f25e638 100644
--- a/arch/arm/include/asm/bug.h
+++ b/arch/arm/include/asm/bug.h
@@ -3,8 +3,6 @@
#include
-#ifdef CONFIG_BUG
-
/*
* Use a suitable undefined instruction to use for ARM/Thumb2 bug handling.
* We need to be careful not to conflict with those used by other modules and
@@ -51,10 +50,10 @@ do {
\
asm volatile(BUG_INSTR_TYPE #__value); \
unreachable(); \
} while (0)
#endif /* CONFIG_DEBUG_BUGVERBOSE */
#define HAVE_ARCH_BUG
-#endif /* CONFIG_BUG */
+#define HAVE_ARCH_BUG_ON
#include
diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h
index 2f03ff0..ba38ebb 100644
--- a/arch/x86/include/asm/bug.h
+++ b/arch/x86/include/asm/bug.h
@@ -1,7 +1,6 @@
#ifndef _ASM_X86_BUG_H
#define _ASM_X86_BUG_H
-#ifdef CONFIG_BUG
#define HAVE_ARCH_BUG
#ifdef CONFIG_DEBUG_BUGVERBOSE
@@ -33,8 +32,6 @@ do {
\
} while (0)
#endif
-#endif /* !CONFIG_BUG */
-
#include
#endif /* _ASM_X86_BUG_H */
diff --git a/include/asm-generic/bug.h b/include/asm-ge
Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.
On 05/28/2013 01:19 AM, Ingo Molnar wrote: > > So I think the same principle applies to it as to any other debugging > code: it's fine to be able to turn debugging off. It's a performance > versus kernel robustness/determinism trade-off. > I suspect, rather, that BUG() should turn into a trap (or jump to a death routine) under any circumstances. The one thing that can be omitted for small configurations are the annotations, which only serve to output a more human-readable error message. -hpa ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.
On Tuesday 28 May 2013, H. Peter Anvin wrote: > On 05/28/2013 01:19 AM, Ingo Molnar wrote: > > > > So I think the same principle applies to it as to any other debugging > > code: it's fine to be able to turn debugging off. It's a performance > > versus kernel robustness/determinism trade-off. > > > > I suspect, rather, that BUG() should turn into a trap (or jump to a > death routine) under any circumstances. The one thing that can be > omitted for small configurations are the annotations, which only serve > to output a more human-readable error message. Right, that is what the patch I just posted does. On a related note, I found that WARN_ON() can no longer be compiled out since there is already code that relies on the side-effects of the condition. I assume that was an intentional change I missed, since it used to be defined so that you could remove it completely. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.
On 05/28/2013 08:43 AM, Arnd Bergmann wrote: > > Right, that is what the patch I just posted does. > > On a related note, I found that WARN_ON() can no longer be compiled > out since there is already code that relies on the side-effects of > the condition. I assume that was an intentional change I missed, > since it used to be defined so that you could remove it completely. > It is possible to define WARN_ON() as: #define WARN_ON(x) ((void)(x)) ... which preserves side effects. -hpa ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4] KVM: PPC: Add support for IOMMU in-kernel handling
On 05/24/2013 09:45:24 PM, David Gibson wrote: On Wed, May 22, 2013 at 04:06:57PM -0500, Scott Wood wrote: > On 05/20/2013 10:06:46 PM, Alexey Kardashevskiy wrote: > >diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c > >index 8465c2a..da6bf61 100644 > >--- a/arch/powerpc/kvm/powerpc.c > >@@ -396,6 +396,7 @@ int kvm_dev_ioctl_check_extension(long ext) > >+++ b/arch/powerpc/kvm/powerpc.c > > break; > > #endif > > case KVM_CAP_SPAPR_MULTITCE: > >+ case KVM_CAP_SPAPR_TCE_IOMMU: > > r = 1; > > break; > > default: > > Don't advertise SPAPR capabilities if it's not book3s -- and > probably there's some additional limitation that would be > appropriate. So, in the case of MULTITCE, that's not quite right. PR KVM can emulate a PAPR system on a BookE machine, and there's no reason not to allow TCE acceleration as well. That might (or might not; consider things like Altivec versus SPE opcode conflict, whether unimplemented SPRs trap, behavior of unprivileged SPRs/instructions, etc) be true in theory, but it's not currently a supported configuration. BookE KVM does not support emulating a different CPU than the host. In the unlikely case that ever changes to the point of allowing PAPR guests on a BookE host, then we can revisit how to properly determine whether the capability is supported, but for now the capability will never be valid in the CONFIG_BOOKE case (though I'd rather see it depend on an appropriate book3s symbol than depend on !BOOKE). Or we could just leave it as is, and let it indicate whether the host kernel supports the feature in general, with the user needing to understand when it's applicable... I'm a bit confused by the documentation, however -- the MULTITCE capability was documented in the "capabilities that can be enabled" section, but I don't see where it can be enabled. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.
On Tuesday 28 May 2013, H. Peter Anvin wrote:
> On 05/28/2013 08:43 AM, Arnd Bergmann wrote:
> >
> > Right, that is what the patch I just posted does.
> >
> > On a related note, I found that WARN_ON() can no longer be compiled
> > out since there is already code that relies on the side-effects of
> > the condition. I assume that was an intentional change I missed,
> > since it used to be defined so that you could remove it completely.
> >
>
> It is possible to define WARN_ON() as:
>
> #define WARN_ON(x) ((void)(x))
>
> ... which preserves side effects.
Yes, actually the return value has to be maintained as well.
The current (!CONFIG_BUG) default implementation is
#define WARN_ON(condition) ({ \
int __ret_warn_on = !!(condition); \
unlikely(__ret_warn_on);\
})
which seems fine.
#define WARN_ON(condition) unlikely(!!(condition))
is probably just as good.
Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] KVM: PPC: Book3S: Add support for H_IPOLL and H_XIRR_X in XICS emulation
On 05/23/2013 08:42:21 PM, Paul Mackerras wrote:
This adds the remaining two hypercalls defined by PAPR for
manipulating
the XICS interrupt controller, H_IPOLL and H_XIRR_X. H_IPOLL returns
information about the priority and pending interrupts for a virtual
cpu, without changing any state. H_XIRR_X is like H_XIRR in that it
reads and acknowledges the highest-priority pending interrupt, but it
also returns the timestamp (timebase register value) from when the
interrupt was first received by the hypervisor. Currently we just
return the current time, since we don't do any software queueing of
virtual interrupts inside the XICS emulation code.
These hcalls are not currently used by Linux guests, but may be in
future.
Signed-off-by: Paul Mackerras
---
Unfortunately I missed these two hcalls in the previous submissions.
It would be good to get this patch into 3.10 so we don't have a
kernel version with these calls missing from the API, in case future
guest kernels want to use them.
Alex, given you're on vacation at the moment, are you OK with Ben
taking this through his tree?
I believe Alex is staying far away from e-mail on his vacation. He's
asked me to fill in for him while he's gone.
The patch itself seems reasonable (though I don't know much about XICS,
and do have one question...), but I'll leave it up to Gleb/Marcelo/Ben
if it should go in for 3.10 and via which tree. I understand the
desire to not have an incomplete ABI in a released version, but Linus
is already grumbling about how much went into rc3, and you say the
hcalls aren't currently used... Are they likely to be used in any
timeframe in which we'd reasonably care about 3.10? If so, would the
effect of not having them implemented be such that it would be worse
than not having in-kernel XICS at all?
@@ -787,6 +804,18 @@ int kvmppc_xics_hcall(struct kvm_vcpu *vcpu, u32
req)
if (!xics || !vcpu->arch.icp)
return H_HARDWARE;
+ /* These requests don't have real-mode implementations at
present */
+ switch (req) {
+ case H_XIRR_X:
+ res = kvmppc_h_xirr(vcpu);
+ kvmppc_set_gpr(vcpu, 4, res);
+ kvmppc_set_gpr(vcpu, 5, get_tb());
+ return rc;
+ case H_IPOLL:
+ rc = kvmppc_h_ipoll(vcpu, kvmppc_get_gpr(vcpu, 4));
+ return rc;
+ }
+
/* Check for real mode returning too hard */
if (xics->real_mode)
return kvmppc_xics_rm_complete(vcpu, req);
Could you explain what's going on here relative to
kvmppc_xics_rm_complete()? What does "returning too hard" mean, and
why must rm_action not be checked for these hcalls?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4] KVM: PPC: Add support for IOMMU in-kernel handling
On 05/26/2013 09:44:24 PM, Alexey Kardashevskiy wrote:
On 05/25/2013 12:45 PM, David Gibson wrote:
> On Wed, May 22, 2013 at 04:06:57PM -0500, Scott Wood wrote:
>> On 05/20/2013 10:06:46 PM, Alexey Kardashevskiy wrote:
>>> diff --git a/arch/powerpc/kvm/powerpc.c
b/arch/powerpc/kvm/powerpc.c
>>> index 8465c2a..da6bf61 100644
>>> --- a/arch/powerpc/kvm/powerpc.c
>>> @@ -396,6 +396,7 @@ int kvm_dev_ioctl_check_extension(long ext)
>>> +++ b/arch/powerpc/kvm/powerpc.c
>>>break;
>>> #endif
>>>case KVM_CAP_SPAPR_MULTITCE:
>>> + case KVM_CAP_SPAPR_TCE_IOMMU:
>>>r = 1;
>>>break;
>>>default:
>>
>> Don't advertise SPAPR capabilities if it's not book3s -- and
>> probably there's some additional limitation that would be
>> appropriate.
>
> So, in the case of MULTITCE, that's not quite right. PR KVM can
> emulate a PAPR system on a BookE machine, and there's no reason not
to
> allow TCE acceleration as well. We can't make it dependent on PAPR
> mode being selected, because that's enabled per-vcpu, whereas these
> capabilities are queried on the VM before the vcpus are created.
>
> CAP_SPAPR_TCE_IOMMU should be dependent on the presence of suitable
> host side hardware (i.e. a PAPR style IOMMU), though.
The capability says that the ioctl is supported. If there is no IOMMU
group
registered, than it will fail with a reasonable error and nobody gets
hurt.
What is the problem?
You could say that about a lot of the capabilities that just advertise
the existence of new ioctls. :-)
Sometimes it's nice to know in advance whether it's supported, before
actually requesting that something happen.
>>> @@ -939,6 +940,9 @@ struct kvm_s390_ucas_mapping {
>>> #define KVM_GET_DEVICE_ATTR _IOW(KVMIO, 0xe2, struct
>>> kvm_device_attr)
>>> #define KVM_HAS_DEVICE_ATTR _IOW(KVMIO, 0xe3, struct
>>> kvm_device_attr)
>>>
>>> +/* ioctl for SPAPR TCE IOMMU */
>>> +#define KVM_CREATE_SPAPR_TCE_IOMMU _IOW(KVMIO, 0xe4, struct
>>> kvm_create_spapr_tce_iommu)
>>
>> Shouldn't this go under the vm ioctl section?
The KVM_CREATE_SPAPR_TCE_IOMMU ioctl (the version for emulated
devices) is
in this section so I decided to keep them together. Wrong?
You decided to keep KVM_CREATE_SPAPR_TCE_IOMMU together with
KVM_CREATE_SPAPR_TCE_IOMMU?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] net: mv643xx_eth: proper initialization for Kirkwood SoCs
Jason, Sorry, I meant to get back to this earlier and it slipped off of my plate. :( On Fri, May 24, 2013 at 11:33:06AM -0600, Jason Gunthorpe wrote: > On Fri, May 24, 2013 at 12:46:36PM -0400, Jason Cooper wrote: > > > > Why are you not keen on this? It seems like normal device driver > > > practice, that is what the data field of of_device_id is typically > > > used for.. > > > > I'm not keen on it because we don't have a document saying "All kirkwood > > SoCs need PSC1 set to X after reset." We know it, but have we tested > > the 6282? > > I disagree. The manul is very clear how PSC1 must be set for proper > operation. Clk125BypassEn bit is used only for loopback testing, it > should never set for driver operation. Similarly PortReset must be > cleared for driver operation. > > It is always safe for the driver to clear these bits, if it knows they > are available. In fact, I would argue the driver should always clear > these bits so that the bootloader isn't relied on to do it. It doesn't > matter if the SOC errantly sets the bit or not, it can *always* be > safely cleared. Great! > Further, I compared my 88F6282/88F6283 manual against the public > 88F6180/88F619x/88F6281 spec and confirmed that the PSC1 layout is the > same. Even better. > So all of these SOC's can share a driver compatible string. Ok, "marvell,kirkwood-eth" works for me then. I think Sebastian already has patches for that. > AFAICT the only reason the driver doesn't touch PSC1 today is because > the PSC1 was introduced in a later IP revision and its presence isn't > auto-detectable. Makes sense. > The last bit of the puzzle to get bootloader independence on kirkwood > is to encode the phy interface type (GMII/RGMII/BASE-X) in the DT so > the entire PSC1 can be set by the driver.. Hmm, let's work on that separately, and later. I've snowballed this attempt enough ;-) Thanks for digging into this for us, Jason. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/cputable: fix oprofile_cpu_type on power8
Maynard informed me that neither the oprofile kernel module nor oprofile
userspace has been updated to support that "legacy" oprofile module
interface for power8, which is indicated by "ppc64/power8." This results
in no samples. The solution is to default to the "timer" type, instead.
The raw entry also should be updated, as "ppc64/ibm-compat-v1" indicates
to oprofile userspace to use "compatibility events" which are obsolete
in ISA 2.07.
Signed-off-by: Nishanth Aravamudan
---
Ben, if this seems reasonable to you, it would be great to get this into
3.10.
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index c60bbec..b8808bc 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -453,7 +453,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
.icache_bsize = 128,
.dcache_bsize = 128,
.oprofile_type = PPC_OPROFILE_POWER4,
- .oprofile_cpu_type = "ppc64/ibm-compat-v1",
+ .oprofile_cpu_type = 0,
.cpu_setup = __setup_cpu_power8,
.cpu_restore= __restore_cpu_power8,
.platform = "power8",
@@ -506,7 +506,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
.dcache_bsize = 128,
.num_pmcs = 6,
.pmc_type = PPC_PMC_IBM,
- .oprofile_cpu_type = "ppc64/power8",
+ .oprofile_cpu_type = 0,
.oprofile_type = PPC_OPROFILE_POWER4,
.cpu_setup = __setup_cpu_power8,
.cpu_restore= __restore_cpu_power8,
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/pci: Improve device hotplug initialization
Commit 37f02195b (powerpc/pci: fix PCI-e devices rescan issue on powerpc
platform) fixes a problem with interrupt and DMA initialization on hot
plugged devices. With this commit, interrupt and DMA initialization for
hot plugged devices is handled in the pci device enable function.
This approach has a couple of drawbacks. First, it creates two code paths
for device initialization, one for hot plugged devices and another for devices
known during the initial PCI scan. Second, the initialization code for hot
plugged devices is only called when the device is enabled, ie typically
in the probe function. Also, the platform specific setup code is called each
time pci_enable_device() is called, not only once during device discovery,
meaning it is actually called multiple times, once for devices discovered
during the initial scan and again each time a driver is re-loaded.
The visible result is that interrupt pins are only assigned to hot plugged
devices when the device driver is loaded. Effectively this changes the PCI
probe API, since pci_dev->irq and the device's dma configuration will now
only be valid after pci_enable() was called at least once. A more subtle
change is that platform specific PCI device setup is moved from device
discovery into the driver's probe function, more specifically into the
pci_enable_device() call.
To fix the inconsistencies, replace pcibios_setup_device() with
pcibios_add_device(). Drop explicit calls to pcibios_setup_device();
this makes pcibios_setup_bus_devices() a noop function which could
eventually be dropped. With this change, device initialization is called
exactly once and consistently for both static and hot plugged devices.
Since pcibios_add_device() is called from pci_device_add(), which initializes
the numa node, drop the now redundant additional numa node initialization.
Cc: Yuanquan Chen
Cc: Benjamin Herrenschmidt
Cc: Hiroo Matsumoto
Signed-off-by: Guenter Roeck
---
arch/powerpc/kernel/pci-common.c | 25 -
1 file changed, 4 insertions(+), 21 deletions(-)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 6053f03..41dd980 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -1004,13 +1004,8 @@ void pcibios_setup_bus_self(struct pci_bus *bus)
ppc_md.pci_dma_bus_setup(bus);
}
-void pcibios_setup_device(struct pci_dev *dev)
+int pcibios_add_device(struct pci_dev *dev)
{
- /* Fixup NUMA node as it may not be setup yet by the generic
-* code and is needed by the DMA init
-*/
- set_dev_node(&dev->dev, pcibus_to_node(dev->bus));
-
/* Hook up default DMA ops */
set_dma_ops(&dev->dev, pci_dma_ops);
set_dma_offset(&dev->dev, PCI_DRAM_OFFSET);
@@ -1023,24 +1018,16 @@ void pcibios_setup_device(struct pci_dev *dev)
pci_read_irq_line(dev);
if (ppc_md.pci_irq_fixup)
ppc_md.pci_irq_fixup(dev);
+
+ return 0;
}
void pcibios_setup_bus_devices(struct pci_bus *bus)
{
- struct pci_dev *dev;
-
pr_debug("PCI: Fixup bus devices %d (%s)\n",
bus->number, bus->self ? pci_name(bus->self) : "PHB");
- list_for_each_entry(dev, &bus->devices, bus_list) {
- /* Cardbus can call us to add new devices to a bus, so ignore
-* those who are already fully discovered
-*/
- if (dev->is_added)
- continue;
-
- pcibios_setup_device(dev);
- }
+ /* nothing to do */
}
void pcibios_set_master(struct pci_dev *dev)
@@ -1479,10 +1466,6 @@ int pcibios_enable_device(struct pci_dev *dev, int mask)
if (ppc_md.pcibios_enable_device_hook(dev))
return -EINVAL;
- /* avoid pcie irq fix up impact on cardbus */
- if (dev->hdr_type != PCI_HEADER_TYPE_CARDBUS)
- pcibios_setup_device(dev);
-
return pci_enable_resources(dev, mask);
}
--
1.7.9.7
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mpc85xx: match with the pci bus address used by u-boot for all p1_p2_rdb_pc boards
On 05/16/2013 01:29:45 AM, Kevin Hao wrote: All these boards use the same configuration file p1_p2_rdb_pc.h in u-boot. So they have the same pci bus address set by the u-boot. But in some of these boards the bus address set in dtb don't match the one used by u-boot. And this will trigger a kernel bug in 32bit kernel and cause the pci device malfunction. For example, on a p2020rdb-pc board the u-boot use the 0xa000 as both bus address and cpu address for one pci controller and then assign bus address such as 0xa4000 to some pci device. But in the kernel, the dtb set the bus address to 0xe000 and the cpu address to 0xa000. The kernel assumes mistakenly the assigned bus address 0xa0004000 in pci device is correct and keep it unchanged. This will definitely cause the pci device malfunction. I have made two patches to fix this in the pci subsystem. http://patchwork.ozlabs.org/patch/243702/ http://patchwork.ozlabs.org/patch/243703/ But I still think it makes sense to set these bus address to match with the u-boot. This issue can't be reproduced on 36bit kernel. But I also tweak the 36bit dtb for the above reason. IIRC the reason for using 0xe000 on all PCIe roots is to maximize the memory that is DMA-addressable without involving swiotlb. Maybe U-Boot should be fixed? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc/mpc85xx: remove the unneeded pci init functions for corenet ds board
On 05/21/2013 07:04:58 AM, Kevin Hao wrote: It also seems that we don't support ISA on all the current corenet ds boards. So picking a primary bus seems useless, remove that function too. IIRC that was due to some bugs in the PPC PCI code in the absence of any primary bus. fsl_pci_assign_primary() will arbitrarily pick one to be primary if there's no ISA. Have the bugs been fixed? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 20/21] powerpc/ps3: remove inline marking of EXPORT_SYMBOL functions
Hi Geert,
On Fri, 2013-05-17 at 18:05 +0200, Geert Uytterhoeven wrote:
> On Thu, May 9, 2013 at 12:36 PM, Denis Efremov
> wrote:
> > -inline u64 ps3_get_spe_id(void *arg)
> > +u64 ps3_get_spe_id(void *arg)
> > {
> > return spu_pdata(arg)->spe_id;
> > }
>
> FYI, this symbol is not used in mainline.
>
> IIRC, it's used for profiling only. Any chance the profile code will
> ever make it
> in mainline?
As I announced (below), I dropped the profiling patches since
ps3-queue-v3.8.
The profiling code does not use ps3_get_spe_id(), so I think we should
remove it. I'll submit a patch.
-Geoff
Forwarded Message
From: Geoff Levand
To: cbe-oss-...@lists.ozlabs.org
Subject: Dropping PS3 oprofile support in v3.8
Date: Wed, 13 Feb 2013 17:30:39 -0800
Hi All,
I'll be dropping the PS3 oprofile patches from my ps3-linux git tree
from linux-3.8. These are the patches:
7f02610 ps3-debugging: Add oprofile test script
49213b6 powerpc/ps3: PS3 oprofile support
aee2985 powerpc/ps3: Add ps3 pmu platform routines
531c3f4 powerpc/ps3: Rearrange order of lpm routines
9d8a7d3 powerpc/cell: Add pmu platform abstraction
6865b99 powerpc/cell: Rearrange order of pmu routines
These patches will still be available in the ps3-queue-v3.7 and earlier
branches for anyone who wants them.
-Geoff
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4] KVM: PPC: Add support for IOMMU in-kernel handling
On 05/29/2013 03:45 AM, Scott Wood wrote:
> On 05/26/2013 09:44:24 PM, Alexey Kardashevskiy wrote:
>> On 05/25/2013 12:45 PM, David Gibson wrote:
>> > On Wed, May 22, 2013 at 04:06:57PM -0500, Scott Wood wrote:
>> >> On 05/20/2013 10:06:46 PM, Alexey Kardashevskiy wrote:
>> >>> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
>> >>> index 8465c2a..da6bf61 100644
>> >>> --- a/arch/powerpc/kvm/powerpc.c
>> >>> @@ -396,6 +396,7 @@ int kvm_dev_ioctl_check_extension(long ext)
>> >>> +++ b/arch/powerpc/kvm/powerpc.c
>> >>> break;
>> >>> #endif
>> >>> case KVM_CAP_SPAPR_MULTITCE:
>> >>> +case KVM_CAP_SPAPR_TCE_IOMMU:
>> >>> r = 1;
>> >>> break;
>> >>> default:
>> >>
>> >> Don't advertise SPAPR capabilities if it's not book3s -- and
>> >> probably there's some additional limitation that would be
>> >> appropriate.
>> >
>> > So, in the case of MULTITCE, that's not quite right. PR KVM can
>> > emulate a PAPR system on a BookE machine, and there's no reason not to
>> > allow TCE acceleration as well. We can't make it dependent on PAPR
>> > mode being selected, because that's enabled per-vcpu, whereas these
>> > capabilities are queried on the VM before the vcpus are created.
>> >
>> > CAP_SPAPR_TCE_IOMMU should be dependent on the presence of suitable
>> > host side hardware (i.e. a PAPR style IOMMU), though.
>>
>>
>> The capability says that the ioctl is supported. If there is no IOMMU group
>> registered, than it will fail with a reasonable error and nobody gets hurt.
>> What is the problem?
>
> You could say that about a lot of the capabilities that just advertise the
> existence of new ioctls. :-)
>
> Sometimes it's nice to know in advance whether it's supported, before
> actually requesting that something happen.
Yes, would be nice. There is just no quick way to know if this real system
supports IOMMU groups. I could add another helper to generic IOMMU code
which would return the number of registered IOMMU groups but it is a bit
too much :)
>> >>> @@ -939,6 +940,9 @@ struct kvm_s390_ucas_mapping {
>> >>> #define KVM_GET_DEVICE_ATTR _IOW(KVMIO, 0xe2, struct
>> >>> kvm_device_attr)
>> >>> #define KVM_HAS_DEVICE_ATTR _IOW(KVMIO, 0xe3, struct
>> >>> kvm_device_attr)
>> >>>
>> >>> +/* ioctl for SPAPR TCE IOMMU */
>> >>> +#define KVM_CREATE_SPAPR_TCE_IOMMU _IOW(KVMIO, 0xe4, struct
>> >>> kvm_create_spapr_tce_iommu)
>> >>
>> >> Shouldn't this go under the vm ioctl section?
>>
>>
>> The KVM_CREATE_SPAPR_TCE_IOMMU ioctl (the version for emulated devices) is
>> in this section so I decided to keep them together. Wrong?
>
> You decided to keep KVM_CREATE_SPAPR_TCE_IOMMU together with
> KVM_CREATE_SPAPR_TCE_IOMMU?
Yes.
--
Alexey
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4] KVM: PPC: Add support for IOMMU in-kernel handling
On 05/28/2013 06:30:40 PM, Alexey Kardashevskiy wrote:
>> >>> @@ -939,6 +940,9 @@ struct kvm_s390_ucas_mapping {
>> >>> #define KVM_GET_DEVICE_ATTR _IOW(KVMIO, 0xe2, struct
>> >>> kvm_device_attr)
>> >>> #define KVM_HAS_DEVICE_ATTR _IOW(KVMIO, 0xe3, struct
>> >>> kvm_device_attr)
>> >>>
>> >>> +/* ioctl for SPAPR TCE IOMMU */
>> >>> +#define KVM_CREATE_SPAPR_TCE_IOMMU _IOW(KVMIO, 0xe4, struct
>> >>> kvm_create_spapr_tce_iommu)
>> >>
>> >> Shouldn't this go under the vm ioctl section?
>>
>>
>> The KVM_CREATE_SPAPR_TCE_IOMMU ioctl (the version for emulated
devices) is
>> in this section so I decided to keep them together. Wrong?
>
> You decided to keep KVM_CREATE_SPAPR_TCE_IOMMU together with
> KVM_CREATE_SPAPR_TCE_IOMMU?
Yes.
Sigh. That's the same thing repeated. There's only one IOCTL.
Nothing is being "kept together".
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4] KVM: PPC: Add support for IOMMU in-kernel handling
On 05/29/2013 09:35 AM, Scott Wood wrote:
> On 05/28/2013 06:30:40 PM, Alexey Kardashevskiy wrote:
>> >> >>> @@ -939,6 +940,9 @@ struct kvm_s390_ucas_mapping {
>> >> >>> #define KVM_GET_DEVICE_ATTR _IOW(KVMIO, 0xe2, struct
>> >> >>> kvm_device_attr)
>> >> >>> #define KVM_HAS_DEVICE_ATTR _IOW(KVMIO, 0xe3, struct
>> >> >>> kvm_device_attr)
>> >> >>>
>> >> >>> +/* ioctl for SPAPR TCE IOMMU */
>> >> >>> +#define KVM_CREATE_SPAPR_TCE_IOMMU _IOW(KVMIO, 0xe4, struct
>> >> >>> kvm_create_spapr_tce_iommu)
>> >> >>
>> >> >> Shouldn't this go under the vm ioctl section?
>> >>
>> >>
>> >> The KVM_CREATE_SPAPR_TCE_IOMMU ioctl (the version for emulated
>> devices) is
>> >> in this section so I decided to keep them together. Wrong?
>> >
>> > You decided to keep KVM_CREATE_SPAPR_TCE_IOMMU together with
>> > KVM_CREATE_SPAPR_TCE_IOMMU?
>>
>> Yes.
>
> Sigh. That's the same thing repeated. There's only one IOCTL. Nothing is
> being "kept together".
Sorry, I meant this ioctl - KVM_CREATE_SPAPR_TCE.
--
Alexey
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4] KVM: PPC: Add support for IOMMU in-kernel handling
On 05/29/2013 02:32 AM, Scott Wood wrote: > On 05/24/2013 09:45:24 PM, David Gibson wrote: >> On Wed, May 22, 2013 at 04:06:57PM -0500, Scott Wood wrote: >> > On 05/20/2013 10:06:46 PM, Alexey Kardashevskiy wrote: >> > >diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c >> > >index 8465c2a..da6bf61 100644 >> > >--- a/arch/powerpc/kvm/powerpc.c >> > >@@ -396,6 +396,7 @@ int kvm_dev_ioctl_check_extension(long ext) >> > >+++ b/arch/powerpc/kvm/powerpc.c >> > > break; >> > > #endif >> > > case KVM_CAP_SPAPR_MULTITCE: >> > >+case KVM_CAP_SPAPR_TCE_IOMMU: >> > > r = 1; >> > > break; >> > > default: >> > >> > Don't advertise SPAPR capabilities if it's not book3s -- and >> > probably there's some additional limitation that would be >> > appropriate. >> >> So, in the case of MULTITCE, that's not quite right. PR KVM can >> emulate a PAPR system on a BookE machine, and there's no reason not to >> allow TCE acceleration as well. > > That might (or might not; consider things like Altivec versus SPE opcode > conflict, whether unimplemented SPRs trap, behavior of unprivileged > SPRs/instructions, etc) be true in theory, but it's not currently a > supported configuration. BookE KVM does not support emulating a different > CPU than the host. In the unlikely case that ever changes to the point of > allowing PAPR guests on a BookE host, then we can revisit how to properly > determine whether the capability is supported, but for now the capability > will never be valid in the CONFIG_BOOKE case (though I'd rather see it > depend on an appropriate book3s symbol than depend on !BOOKE). > > Or we could just leave it as is, and let it indicate whether the host > kernel supports the feature in general, with the user needing to understand > when it's applicable... I'm a bit confused by the documentation, however > -- the MULTITCE capability was documented in the "capabilities that can be > enabled" section, but I don't see where it can be enabled. True, it cannot be enabled (but it could be enabled a long time ago), it is either supported or not, I'll fix the documentation. Thanks! -- Alexey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] KVM: PPC: Book3S: Add support for H_IPOLL and H_XIRR_X in XICS emulation
On Tue, 2013-05-28 at 12:41 -0500, Scott Wood wrote:
> I believe Alex is staying far away from e-mail on his vacation. He's
> asked me to fill in for him while he's gone.
>
> The patch itself seems reasonable (though I don't know much about XICS,
> and do have one question...), but I'll leave it up to Gleb/Marcelo/Ben
> if it should go in for 3.10 and via which tree. I understand the
> desire to not have an incomplete ABI in a released version, but Linus
> is already grumbling about how much went into rc3, and you say the
> hcalls aren't currently used... Are they likely to be used in any
> timeframe in which we'd reasonably care about 3.10?
Yes. I'd like to have them in. Their implementation is actually fairly
trivial and they cannot be emulated by qemu if the rest of the XICS is
in the kernel, so it's a problem.
> If so, would the
> effect of not having them implemented be such that it would be worse
> than not having in-kernel XICS at all?
Well, that would mean that running that potential future kernel that
uses them (or some other OS that already uses them) would not work
without the user explicitly disable in kernel irq chip.
> > @@ -787,6 +804,18 @@ int kvmppc_xics_hcall(struct kvm_vcpu *vcpu, u32
> > req)
> > if (!xics || !vcpu->arch.icp)
> > return H_HARDWARE;
> >
> > + /* These requests don't have real-mode implementations at
> > present */
> > + switch (req) {
> > + case H_XIRR_X:
> > + res = kvmppc_h_xirr(vcpu);
> > + kvmppc_set_gpr(vcpu, 4, res);
> > + kvmppc_set_gpr(vcpu, 5, get_tb());
> > + return rc;
> > + case H_IPOLL:
> > + rc = kvmppc_h_ipoll(vcpu, kvmppc_get_gpr(vcpu, 4));
> > + return rc;
> > + }
> > +
> > /* Check for real mode returning too hard */
> > if (xics->real_mode)
> > return kvmppc_xics_rm_complete(vcpu, req);
>
> Could you explain what's going on here relative to
> kvmppc_xics_rm_complete()? What does "returning too hard" mean, and
> why must rm_action not be checked for these hcalls?
This is related to how we handle some hcalls in real mode as a fast
path. The real-mode stuff cannot handle cases that require for example a
re-emit of the interrupt, a reject, etc... so in some cases, it returns
H_TOO_HARD which causes KVM to exit and try to handle the hcall again in
kernel virtual mode.
When doing so as the result of a XICS hcall, it sets a bit mask of
"tasks" to handle in virtual mode (because it will have already
partially done the operation, it cannot just re-play the whole hcall).
So when real-mode is supported we must not just call the normal virtual
mode version of the hcalls, we instead go to kvmppc_xics_rm_complete()
to handle those "tasks".
However, for those 2 "missing" hcalls, we have no real mode
implementation at all (we didn't bother, we will do that later if
needed, it's purely a performance issue). So we need to fully handle
them in virtual mode, and we know there will be no "tasks" to handle in
rm_complete.
We could have done a real mode variant but we wanted to keep the patch
as small as possible for 3.10.
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] driver: tty: add missing unregister in err case
Libo Chen wrote: when platform_driver_register broken, we should unregister ucc_uart_driver Signed-off-by: Libo chen Acked-by: Timur Tabi Thanks for catching this. -- Timur Tabi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] driver: tty: add missing unregister in err case
when platform_driver_register broken, we should unregister ucc_uart_driver
Signed-off-by: Libo chen
---
drivers/tty/serial/ucc_uart.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/ucc_uart.c b/drivers/tty/serial/ucc_uart.c
index 7355303..f86f447 100644
--- a/drivers/tty/serial/ucc_uart.c
+++ b/drivers/tty/serial/ucc_uart.c
@@ -1518,9 +1518,11 @@ static int __init ucc_uart_init(void)
}
ret = platform_driver_register(&ucc_uart_of_driver);
- if (ret)
+ if (ret) {
printk(KERN_ERR
"ucc-uart: could not register platform driver\n");
+ uart_unregister_driver(&ucc_uart_driver);
+ }
return ret;
}
--
1.7.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
