* Re: [RFC PATCH 09/11] kvm: simplify processor compat check
From: Aneesh Kumar K.V @ 2013-09-29 15:05 UTC (permalink / raw)
To: Gleb Natapov
Cc: <kvm@vger.kernel.org> list, Alexander Graf, kvm-ppc,
Paul Mackerras, Paolo Bonzini, linuxppc-dev
In-Reply-To: <20130929085800.GO17294@redhat.com>
Gleb Natapov <gleb@redhat.com> writes:
> On Sat, Sep 28, 2013 at 09:06:47PM +0530, Aneesh Kumar K.V wrote:
>> Paolo Bonzini <pbonzini@redhat.com> writes:
>>
>> > Il 27/09/2013 15:13, Aneesh Kumar K.V ha scritto:
>> >> Alexander Graf <agraf@suse.de> writes:
>> >>
>> >>> On 27.09.2013, at 12:03, Aneesh Kumar K.V wrote:
>> >>>
>> >>>> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>> >>>
>> >>> Missing patch description.
>> >>>
>> >>>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>> >>>
>> >>> I fail to see how this really simplifies things, but at the end of the
>> >>> day it's Gleb's and Paolo's call.
>> >>
>> >> will do. It avoid calling
>> >>
>> >> for_each_online_cpu(cpu) {
>> >> smp_call_function_single()
>> >>
>> >> on multiple architecture.
>> >
>> > I agree with Alex.
>> >
>> > The current code is not specially awesome; having
>> > kvm_arch_check_processor_compat take an int* disguised as a void* is a
>> > bit ugly indeed.
>> >
>> > However, the API makes sense and tells you that it is being passed as a
>> > callback (to smp_call_function_single in this case).
>>
>> But whether to check on all cpus or not is arch dependent right?.
>> IIUC only x86 and ppc64 need to do that. Also on ppc64 it really
>> depends on whether HV or PR. We need to check on all cpus only if it is
>> HV.
>>
>> >
>> > You are making the API more complicated to use on the arch layer
>> > (because arch maintainers now have to think "do I need to check this on
>> > all online CPUs?") and making the "leaf" POWER code less legible because
>> > it still has the weird void()(void *) calling convention.
>> >
>>
>> IIUC what we wanted to check is to find out whether kvm can run on this
>> system. That is really an arch specific check. So for core kvm the call
>> should be a simple
>>
>> if (kvm_arch_check_process_compat() < 0)
>> error;
> We have that already, just return error from kvm_arch_hardware_setup. This
> is specific processor compatibility check and you are arguing that the
> processor check should be part of kvm_arch_hardware_setup().
What about the success case ?. ie, on arch like arm we do
void kvm_arch_check_processor_compat(void *rtn)
{
*(int *)rtn = 0;
}
for_each_online_cpu(cpu) {
smp_call_function_single(cpu,
kvm_arch_check_processor_compat,
&r, 1);
if (r < 0)
goto out_free_1;
}
There is no need to do that for loop for arm.
The only reason I wanted this patch in the series is to make
kvm_arch_check_processor_compat take additional argument opaque.
I am dropping that requirement in the last patch. Considering
that we have objection to this one, I will drop this patch in
the next posting by rearranging the patches.
-aneesh
^ permalink raw reply
* [PATCH] powerpc: fix section mismatch warning in free_lppacas
From: Vladimir Murzin @ 2013-09-29 12:41 UTC (permalink / raw)
To: linuxppc-dev; +Cc: geoff, Vladimir Murzin, paulus
While cross-building for PPC64 I've got bunch of
WARNING: arch/powerpc/kernel/built-in.o(.text.unlikely+0x2d2): Section
mismatch in reference from the function .free_lppacas() to the variable
.init.data:lppaca_size The function .free_lppacas() references the variable
__initdata lppaca_size. This is often because .free_lppacas lacks a __initdata
annotation or the annotation of lppaca_size is wrong.
Fix it by using proper annotation for free_lppacas. Additionally, annotate
{allocate,new}_llpcas properly.
Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
---
arch/powerpc/kernel/paca.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
index 3fc16e3..0620eaa 100644
--- a/arch/powerpc/kernel/paca.c
+++ b/arch/powerpc/kernel/paca.c
@@ -46,7 +46,7 @@ struct lppaca lppaca[] = {
static struct lppaca *extra_lppacas;
static long __initdata lppaca_size;
-static void allocate_lppacas(int nr_cpus, unsigned long limit)
+static void __init allocate_lppacas(int nr_cpus, unsigned long limit)
{
if (nr_cpus <= NR_LPPACAS)
return;
@@ -57,7 +57,7 @@ static void allocate_lppacas(int nr_cpus, unsigned long limit)
PAGE_SIZE, limit));
}
-static struct lppaca *new_lppaca(int cpu)
+static struct lppaca * __init new_lppaca(int cpu)
{
struct lppaca *lp;
@@ -70,7 +70,7 @@ static struct lppaca *new_lppaca(int cpu)
return lp;
}
-static void free_lppacas(void)
+static void __init free_lppacas(void)
{
long new_size = 0, nr;
--
1.8.1.5
^ permalink raw reply related
* Re: [PATCH 2/2] pci: fsl: rework PCI driver compatible with Layerscape
From: Lian Minghuan-b31939 @ 2013-09-29 11:51 UTC (permalink / raw)
To: Scott Wood, Minghuan Lian
Cc: Bjorn Helgaas, linux-pci, linuxppc-dev, Zang Roy-R61911
In-Reply-To: <1380300847.24959.394.camel@snotra.buserror.net>
Hi Scott,
please see my comments inline.
On 09/28/2013 12:54 AM, Scott Wood wrote:
> On Wed, 2013-09-18 at 19:02 +0800, Minghuan Lian wrote:
>> @@ -592,6 +719,7 @@ int fsl_pci_mcheck_exception(struct pt_regs *regs)
>> #if defined(CONFIG_FSL_SOC_BOOKE) || defined(CONFIG_PPC_86xx)
>>
>> struct device_node *fsl_pci_primary;
>> +extern const struct of_device_id fsl_pci_ids[];
> Externs go in headers.
[Minghuan] ok.
>
>> -static int fsl_pci_probe(struct platform_device *pdev)
>> +static int __init fsl_pci_probe(struct platform_device *pdev)
>> {
>> int ret;
>> - struct device_node *node;
>> + struct fsl_pci *pci;
>> +
>> + if (!of_device_is_available(pdev->dev.of_node)) {
>> + dev_warn(&pdev->dev, "disabled\n");
>> + return -ENODEV;
>> + }
> This should be dev_dbg().
[Minghuan] ok.
>> -#ifdef CONFIG_PM
>> -static int fsl_pci_resume(struct device *dev)
>> +static int __exit fsl_pci_remove(struct platform_device *pdev)
> Why __exit? What happens if someone unbinds the PCI controller via
> sysfs?
>
[Minghuan] Sorry. should remove __exit
>> +/*
>> + * Structure of a PCI controller (host bridge)
>> + */
>> +struct fsl_pci {
>> + struct list_head node;
>> + int is_pcie;
> bool is_pcie;
[Minghuan] ok.
>> +/* Return link status 0-> link, 1-> no link */
>> +int fsl_pci_check_link(struct fsl_pci *pci);
> bool
[Minghuan] ok.
>> +
>> +/*
>> + * The fsl_arch_* functions are arch hooks. Those functions are
>> + * implemented as weak symbols so that they can be overridden by
>> + * architecture specific code if needed.
>> + */
>> +
>> +/* Return PCI64 DMA offset */
>> +u64 fsl_arch_pci64_dma_offset(void);
> Is this always guaranteed to exist?
[Minghuan] Yes. I define a __weak implementation in pci-fsl.c
>> +/* Register PCI/PCIe controller to architecture system */
>> +int __weak fsl_arch_pci_sys_register(struct fsl_pci *pci);
>> +
>> +/* Remove PCI/PCIe controller from architecture system */
>> +void __weak fsl_arch_pci_sys_remove(struct fsl_pci *pci);
> Why do these need to be weak? Won't there be exactly one implementation
> per supported arch?
[Minghuan] I added __weak for compiling kernel when selecting pci-fsl
module but
there is no related arch pci implementation.
I can remove the __weak, and use
"depends on FSL_SOC_BOOKE || PPC_86xx" in Kconfig to make sure there is
one implementation
of supported arch.
> -Scott
>
>
^ permalink raw reply
* Re: [RFC PATCH 09/11] kvm: simplify processor compat check
From: Gleb Natapov @ 2013-09-29 8:58 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: <kvm@vger.kernel.org> list, Alexander Graf, kvm-ppc,
Paul Mackerras, Paolo Bonzini, linuxppc-dev
In-Reply-To: <87mwmx9cvk.fsf@linux.vnet.ibm.com>
On Sat, Sep 28, 2013 at 09:06:47PM +0530, Aneesh Kumar K.V wrote:
> Paolo Bonzini <pbonzini@redhat.com> writes:
>
> > Il 27/09/2013 15:13, Aneesh Kumar K.V ha scritto:
> >> Alexander Graf <agraf@suse.de> writes:
> >>
> >>> On 27.09.2013, at 12:03, Aneesh Kumar K.V wrote:
> >>>
> >>>> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
> >>>
> >>> Missing patch description.
> >>>
> >>>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> >>>
> >>> I fail to see how this really simplifies things, but at the end of the
> >>> day it's Gleb's and Paolo's call.
> >>
> >> will do. It avoid calling
> >>
> >> for_each_online_cpu(cpu) {
> >> smp_call_function_single()
> >>
> >> on multiple architecture.
> >
> > I agree with Alex.
> >
> > The current code is not specially awesome; having
> > kvm_arch_check_processor_compat take an int* disguised as a void* is a
> > bit ugly indeed.
> >
> > However, the API makes sense and tells you that it is being passed as a
> > callback (to smp_call_function_single in this case).
>
> But whether to check on all cpus or not is arch dependent right?.
> IIUC only x86 and ppc64 need to do that. Also on ppc64 it really
> depends on whether HV or PR. We need to check on all cpus only if it is
> HV.
>
> >
> > You are making the API more complicated to use on the arch layer
> > (because arch maintainers now have to think "do I need to check this on
> > all online CPUs?") and making the "leaf" POWER code less legible because
> > it still has the weird void()(void *) calling convention.
> >
>
> IIUC what we wanted to check is to find out whether kvm can run on this
> system. That is really an arch specific check. So for core kvm the call
> should be a simple
>
> if (kvm_arch_check_process_compat() < 0)
> error;
We have that already, just return error from kvm_arch_hardware_setup. This
is specific processor compatibility check and you are arguing that the
processor check should be part of kvm_arch_hardware_setup().
>
> Now how each arch figure out whether kvm can run on this system should
> be arch specific. For x86 we do need to check all the cpus. On ppc64 for
> HV we need to. For other archs we always allow kvm.
>
This is really a sanity check. Theoretically on x86 we also should
not need to check all cpus since SMP configuration with different cpu
models is not supported by the architecture (AFAIK), but bugs happen
(BIOS bugs may cause difference in capabilities for instance). So some
arches opted out from this sanity check for now and this is their choice,
but the code makes it explicit what are we checking here.
>
> > If anything, you could change kvm_arch_check_processor_compat to return
> > an int and accept no argument, and introduce a wrapper that kvm_init
> > passes to smp_call_function_single.
>
> What i am suggesting in the patch is to avoid calling
> smp_call_function_single from kvm_init and let arch decide whether to
> check on all cpus or not.
>
> -aneesh
--
Gleb.
^ permalink raw reply
* RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
From: Wang Dongsheng-B40534 @ 2013-09-29 6:57 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org, Bhushan Bharat-R65777
In-Reply-To: <1380317594.24959.490.camel@snotra.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogU2F0dXJkYXksIFNlcHRlbWJlciAyOCwgMjAxMyA1OjMzIEFNDQo+IFRvOiBX
YW5nIERvbmdzaGVuZy1CNDA1MzQNCj4gQ2M6IFdvb2QgU2NvdHQtQjA3NDIxOyBCaHVzaGFuIEJo
YXJhdC1SNjU3Nzc7IGxpbnV4cHBjLQ0KPiBkZXZAbGlzdHMub3psYWJzLm9yZw0KPiBTdWJqZWN0
OiBSZTogW1BBVENIIHY0IDQvNF0gcG93ZXJwYy84NXh4OiBhZGQgc3lzZnMgZm9yIHB3MjAgc3Rh
dGUgYW5kDQo+IGFsdGl2ZWMgaWRsZQ0KPiANCj4gT24gVGh1LCAyMDEzLTA5LTI2IGF0IDIyOjM0
IC0wNTAwLCBXYW5nIERvbmdzaGVuZy1CNDA1MzQgd3JvdGU6DQo+ID4NCj4gPiA+IC0tLS0tT3Jp
Z2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBXb29kIFNjb3R0LUIwNzQyMQ0KPiA+ID4g
U2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMjcsIDIwMTMgNTozNyBBTQ0KPiA+ID4gVG86IFdhbmcg
RG9uZ3NoZW5nLUI0MDUzNA0KPiA+ID4gQ2M6IEJodXNoYW4gQmhhcmF0LVI2NTc3NzsgV29vZCBT
Y290dC1CMDc0MjE7IGxpbnV4cHBjLQ0KPiA+ID4gZGV2QGxpc3RzLm96bGFicy5vcmcNCj4gPiA+
IFN1YmplY3Q6IFJlOiBbUEFUQ0ggdjQgNC80XSBwb3dlcnBjLzg1eHg6IGFkZCBzeXNmcyBmb3Ig
cHcyMCBzdGF0ZQ0KPiA+ID4gYW5kIGFsdGl2ZWMgaWRsZQ0KPiA+ID4NCj4gPiA+IE9uIFRodSwg
MjAxMy0wOS0yNiBhdCAwMToxOCAtMDUwMCwgV2FuZyBEb25nc2hlbmctQjQwNTM0IHdyb3RlOg0K
PiA+ID4gPg0KPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4g
RnJvbTogQmh1c2hhbiBCaGFyYXQtUjY1Nzc3DQo+ID4gPiA+ID4gU2VudDogVGh1cnNkYXksIFNl
cHRlbWJlciAyNiwgMjAxMyAxMjoyMyBQTQ0KPiA+ID4gPiA+IFRvOiBXYW5nIERvbmdzaGVuZy1C
NDA1MzQ7IFdvb2QgU2NvdHQtQjA3NDIxDQo+ID4gPiA+ID4gQ2M6IGxpbnV4cHBjLWRldkBsaXN0
cy5vemxhYnMub3JnDQo+ID4gPiA+ID4gU3ViamVjdDogUkU6IFtQQVRDSCB2NCA0LzRdIHBvd2Vy
cGMvODV4eDogYWRkIHN5c2ZzIGZvciBwdzIwDQo+ID4gPiA+ID4gc3RhdGUgYW5kIGFsdGl2ZWMg
aWRsZQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gLS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiA+IEZyb206IFdhbmcgRG9uZ3NoZW5nLUI0
MDUzNA0KPiA+ID4gPiA+ID4gU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAyNiwgMjAxMyA4OjAy
IEFNDQo+ID4gPiA+ID4gPiBUbzogV29vZCBTY290dC1CMDc0MjENCj4gPiA+ID4gPiA+IENjOiBC
aHVzaGFuIEJoYXJhdC1SNjU3Nzc7IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnDQo+ID4g
PiA+ID4gPiBTdWJqZWN0OiBSRTogW1BBVENIIHY0IDQvNF0gcG93ZXJwYy84NXh4OiBhZGQgc3lz
ZnMgZm9yIHB3MjANCj4gPiA+ID4gPiA+IHN0YXRlIGFuZCBhbHRpdmVjIGlkbGUNCj4gPiA+ID4g
PiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiA+ID4gRnJvbTogV29vZCBTY290dC1CMDc0MjENCj4g
PiA+ID4gPiA+ID4gU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAyNiwgMjAxMyAxOjU3IEFNDQo+
ID4gPiA+ID4gPiA+IFRvOiBXYW5nIERvbmdzaGVuZy1CNDA1MzQNCj4gPiA+ID4gPiA+ID4gQ2M6
IEJodXNoYW4gQmhhcmF0LVI2NTc3NzsgV29vZCBTY290dC1CMDc0MjE7IGxpbnV4cHBjLQ0KPiA+
ID4gPiA+ID4gPiBkZXZAbGlzdHMub3psYWJzLm9yZw0KPiA+ID4gPiA+ID4gPiBTdWJqZWN0OiBS
ZTogW1BBVENIIHY0IDQvNF0gcG93ZXJwYy84NXh4OiBhZGQgc3lzZnMgZm9yIHB3MjANCj4gPiA+
ID4gPiA+ID4gc3RhdGUgYW5kIGFsdGl2ZWMgaWRsZQ0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+
ID4gPiBPbiBXZWQsIDIwMTMtMDktMjUgYXQgMDM6MTAgLTA1MDAsIFdhbmcgRG9uZ3NoZW5nLUI0
MDUzNA0KPiB3cm90ZToNCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4gLS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiA+ID4gPiA+IEZyb206IEJodXNoYW4gQmhh
cmF0LVI2NTc3Nw0KPiA+ID4gPiA+ID4gPiA+ID4gU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIg
MjUsIDIwMTMgMjoyMyBQTQ0KPiA+ID4gPiA+ID4gPiA+ID4gVG86IFdhbmcgRG9uZ3NoZW5nLUI0
MDUzNDsgV29vZCBTY290dC1CMDc0MjENCj4gPiA+ID4gPiA+ID4gPiA+IENjOiBsaW51eHBwYy1k
ZXZAbGlzdHMub3psYWJzLm9yZzsgV2FuZyBEb25nc2hlbmctQjQwNTM0DQo+ID4gPiA+ID4gPiA+
ID4gPiBTdWJqZWN0OiBSRTogW1BBVENIIHY0IDQvNF0gcG93ZXJwYy84NXh4OiBhZGQgc3lzZnMg
Zm9yDQo+ID4gPiA+ID4gPiA+ID4gPiBwdzIwIHN0YXRlIGFuZCBhbHRpdmVjIGlkbGUNCj4gPiA+
ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+
ID4gPiA+ID4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiA+ID4g
PiA+ID4gRnJvbTogTGludXhwcGMtZGV2IFttYWlsdG86bGludXhwcGMtZGV2LQ0KPiA+ID4gPiA+
ID4gPiA+ID4gPiBib3VuY2VzK2JoYXJhdC5iaHVzaGFuPWZyZWVzY2FsZS5jb21AbGlzdHMub3ps
YWJzLm9yZ10NCj4gPiA+ID4gPiA+ID4gPiA+ID4gYm91bmNlcytPbiBCZWhhbGYgT2YgRG9uZ3No
ZW5nDQo+ID4gPiA+ID4gPiA+ID4gPiA+IFdhbmcNCj4gPiA+ID4gPiA+ID4gPiA+ID4gU2VudDog
VHVlc2RheSwgU2VwdGVtYmVyIDI0LCAyMDEzIDI6NTkgUE0NCj4gPiA+ID4gPiA+ID4gPiA+ID4g
VG86IFdvb2QgU2NvdHQtQjA3NDIxDQo+ID4gPiA+ID4gPiA+ID4gPiA+IENjOiBsaW51eHBwYy1k
ZXZAbGlzdHMub3psYWJzLm9yZzsgV2FuZw0KPiA+ID4gPiA+ID4gPiA+ID4gPiBEb25nc2hlbmct
QjQwNTM0DQo+ID4gPiA+ID4gPiA+ID4gPiA+IFN1YmplY3Q6IFtQQVRDSCB2NCA0LzRdIHBvd2Vy
cGMvODV4eDogYWRkIHN5c2ZzIGZvcg0KPiA+ID4gPiA+ID4gPiA+ID4gPiBwdzIwIHN0YXRlIGFu
ZCBhbHRpdmVjIGlkbGUNCj4gPiA+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+ID4g
RnJvbTogV2FuZyBEb25nc2hlbmcgPGRvbmdzaGVuZy53YW5nQGZyZWVzY2FsZS5jb20+DQo+ID4g
PiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPiA+IEFkZCBhIHN5cyBpbnRlcmZhY2Ug
dG8gZW5hYmxlL2RpYWJsZSBwdzIwIHN0YXRlIG9yDQo+ID4gPiA+ID4gPiA+ID4gPiA+IGFsdGl2
ZWMgaWRsZSwgYW5kIGNvbnRyb2wgdGhlIHdhaXQgZW50cnkgdGltZS4NCj4gPiA+ID4gPiA+ID4g
PiA+ID4NCj4gPiA+ID4gPiA+ID4gPiA+ID4gRW5hYmxlL0Rpc2FibGUgaW50ZXJmYWNlOg0KPiA+
ID4gPiA+ID4gPiA+ID4gPiAwLCBkaXNhYmxlLiAxLCBlbmFibGUuDQo+ID4gPiA+ID4gPiA+ID4g
PiA+IC9zeXMvZGV2aWNlcy9zeXN0ZW0vY3B1L2NwdVgvcHcyMF9zdGF0ZQ0KPiA+ID4gPiA+ID4g
PiA+ID4gPiAvc3lzL2RldmljZXMvc3lzdGVtL2NwdS9jcHVYL2FsdGl2ZWNfaWRsZQ0KPiA+ID4g
PiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+ID4gPiBTZXQgd2FpdCB0aW1lIGludGVyZmFj
ZTooTmFub3NlY29uZCkNCj4gPiA+ID4gPiA+ID4gPiA+ID4gL3N5cy9kZXZpY2VzL3N5c3RlbS9j
cHUvY3B1WC9wdzIwX3dhaXRfdGltZQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiAvc3lzL2RldmljZXMv
c3lzdGVtL2NwdS9jcHVYL2FsdGl2ZWNfaWRsZV93YWl0X3RpbWUNCj4gPiA+ID4gPiA+ID4gPiA+
ID4gRXhhbXBsZTogQmFzZSBvbiBUQmZyZXEgaXMgNDFNSFouDQo+ID4gPiA+ID4gPiA+ID4gPiA+
IDF+NDcobnMpOiBUQls2M10NCj4gPiA+ID4gPiA+ID4gPiA+ID4gNDh+OTUobnMpOiBUQls2Ml0N
Cj4gPiA+ID4gPiA+ID4gPiA+ID4gOTZ+MTkxKG5zKTogVEJbNjFdDQo+ID4gPiA+ID4gPiA+ID4g
PiA+IDE5Mn4zODMobnMpOiBUQls2Ml0NCj4gPiA+ID4gPiA+ID4gPiA+ID4gMzg0fjc2Nyhucyk6
IFRCWzYwXQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiAuLi4NCj4gPiA+ID4gPiA+ID4gPiA+ID4NCj4g
PiA+ID4gPiA+ID4gPiA+ID4gU2lnbmVkLW9mZi1ieTogV2FuZyBEb25nc2hlbmcNCj4gPiA+ID4g
PiA+ID4gPiA+ID4gPGRvbmdzaGVuZy53YW5nQGZyZWVzY2FsZS5jb20+DQo+ID4gPiA+ID4gPiA+
ID4gPiA+IC0tLQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiAqdjQ6DQo+ID4gPiA+ID4gPiA+ID4gPiA+
IE1vdmUgY29kZSBmcm9tIDg1eHgvY29tbW9uLmMgdG8ga2VybmVsL3N5c2ZzLmMuDQo+ID4gPiA+
ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPiA+IFJlbW92ZSBoYXNfcHcyMF9hbHRpdmVj
X2lkbGUgZnVuY3Rpb24uDQo+ID4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPiA+
IENoYW5nZSB3YWl0ICJlbnRyeV9iaXQiIHRvIHdhaXQgdGltZS4NCj4gPiA+ID4gPiA+ID4gPiA+
ID4NCj4gPiA+ID4gPiA+ID4gPiA+ID4gIGFyY2gvcG93ZXJwYy9rZXJuZWwvc3lzZnMuYyB8IDI5
MQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKw0KPiA+ID4gPiA+ID4gPiA+ID4gPiAgMSBmaWxlIGNoYW5nZWQsIDI5MSBpbnNl
cnRpb25zKCspDQo+ID4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPiA+IGRpZmYg
LS1naXQgYS9hcmNoL3Bvd2VycGMva2VybmVsL3N5c2ZzLmMNCj4gPiA+ID4gPiA+ID4gPiA+ID4g
Yi9hcmNoL3Bvd2VycGMva2VybmVsL3N5c2ZzLmMgaW5kZXggMjdhOTBiOS4uMjNmZWNlNg0KPiA+
ID4gPiA+ID4gPiA+ID4gPiAxMDA2NDQNCj4gPiA+ID4gPiA+ID4gPiA+ID4gLS0tIGEvYXJjaC9w
b3dlcnBjL2tlcm5lbC9zeXNmcy5jDQo+ID4gPiA+ID4gPiA+ID4gPiA+ICsrKyBiL2FyY2gvcG93
ZXJwYy9rZXJuZWwvc3lzZnMuYw0KPiA+ID4gPiA+ID4gPiA+ID4gPiBAQCAtODUsNiArODUsMjc5
IEBAIF9fc2V0dXAoInNtdC1zbm9vemUtZGVsYXk9IiwNCj4gPiA+ID4gPiA+ID4gPiA+ID4gc2V0
dXBfc210X3Nub296ZV9kZWxheSk7DQo+ID4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+
ID4gPiA+ICAjZW5kaWYgLyogQ09ORklHX1BQQzY0ICovDQo+ID4gPiA+ID4gPiA+ID4gPiA+DQo+
ID4gPiA+ID4gPiA+ID4gPiA+ICsjaWZkZWYgQ09ORklHX0ZTTF9TT0MNCj4gPiA+ID4gPiA+ID4g
PiA+ID4gKyNkZWZpbmUgTUFYX0JJVAkJNjMNCj4gPiA+ID4gPiA+ID4gPiA+ID4gKw0KPiA+ID4g
PiA+ID4gPiA+ID4gPiArc3RhdGljIHU2NCBwdzIwX3d0Ow0KPiA+ID4gPiA+ID4gPiA+ID4gPiAr
c3RhdGljIHU2NCBhbHRpdmVjX2lkbGVfd3Q7DQo+ID4gPiA+ID4gPiA+ID4gPiA+ICsNCj4gPiA+
ID4gPiA+ID4gPiA+ID4gK3N0YXRpYyB1bnNpZ25lZCBpbnQgZ2V0X2lkbGVfdGlja3NfYml0KHU2
NCBucykgew0KPiA+ID4gPiA+ID4gPiA+ID4gPiArCXU2NCBjeWNsZTsNCj4gPiA+ID4gPiA+ID4g
PiA+ID4gKw0KPiA+ID4gPiA+ID4gPiA+ID4gPiArCWN5Y2xlID0gZGl2X3U2NChucywgMTAwMCAv
IHRiX3RpY2tzX3Blcl91c2VjKTsNCj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4g
PiBXaGVuIHRiX3RpY2tzX3Blcl91c2VjICA+IDEwMDAgKHRpbWViYXNlIGZyZXF1ZW5jeSA+DQo+
ID4gPiA+ID4gPiA+ID4gPiAxR0h6KSB0aGVuIHRoaXMgd2lsbCBhbHdheXMgYmUgbnMsIHdoaWNo
IGlzIG5vdCBjb3JyZWN0LA0KPiBubz8NCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gQWN0
dWFsbHkgaXQnbGwgYmUgYSBkaXZpZGUgYnkgemVybyBpbiB0aGF0IGNhc2UuDQo+ID4gPiA+ID4g
PiA+DQo+ID4gPiA+ID4gPiB0Yl90aWNrc19wZXJfdXNlYyA9IHBwY190Yl9mcmVxIC8gMTAwMDAw
MDsgTWVhbnMgVEIgZnJlcQ0KPiA+ID4gPiA+ID4gc2hvdWxkIGJlIG1vcmUgdGhhbiAxTUhaLg0K
PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IGlmIHBwY190Yl9mcmVxIGxlc3MgdGhhbiAxMDAwMDAw
LCB0aGUgdGJfdGlja3NfcGVyX3VzZWMgd2lsbA0KPiA+ID4gPiA+ID4gYmUgYSBkaXZpZGUgYnkg
emVyby4NCj4gPiA+ID4gPiA+IElmIHRoaXMgY29uZGl0aW9uIGlzIGVzdGFibGlzaGVkLCBJIHRo
aW5rIGtlcm5lbCBjYW5ub3Qgd29yaw0KPiA+ID4gPiA+ID4gYXMgYQ0KPiA+ID4gPiA+IG5vcm1h
bC4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBTbyBJIHRoaW5rIHdlIG5lZWQgdG8gYmVsaWV2
ZSB0aGF0IHRoZSB2YXJpYWJsZSBpcyBub3QgemVyby4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFdl
IGRvIGJlbGlldmUgaXQgaXMgbm9uLXplcm8gYnV0IGdyZWF0ZXIgdGhhbiAxMDAwIDopDQo+ID4g
PiA+ID4NCj4gPiA+ID4gPiA+IEFuZCBJIHRoaW5rIFRCIGZyZXENCj4gPiA+ID4gPiA+IHNob3Vs
ZCBub3QgbGVzcyB0aGFuIDFNSFogb24gUFBDIHBsYXRmb3JtLCBiZWNhdXNlIGlmIFRCIGZyZXEN
Cj4gPiA+ID4gPiA+IGxlc3MgdGhhbiAxTUhaLCB0aGUgcHJlY2lzaW9uIHRpbWUgd2lsbCBiZWNv
bWUgdmVyeSBwb29yIGFuZA0KPiA+ID4gPiA+ID4gc3lzdGVtIHJlc3BvbnNlIHRpbWUgd2lsbCBi
ZSBzbG93ZXIuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBOb3Qgc3VyZSB3aGF0IHlvdSBhcmUgZGVz
Y3JpYmluZyBoZXJlIHJlbGF0ZWQgdG8gZGl2aWRlIGJ5IHplcm8NCj4gPiA+ID4gPiB3ZSBhcmUg
bWVudGlvbmluZy4NCj4gPiA+ID4gPiBZb3UgYXJlIHRhbGtpbmcgYWJvdXQgaWYgdGJfdGlja3Nf
cGVyX3VzZWMgaXMgWkVSTyBhbmQgd2UgYXJlDQo+ID4gPiA+ID4gdGFsa2luZyBhYm91dCBpZiAo
MTAwMC90Yl90aWNrc19wZXJfdXNlYykgd2lsbCBiZSB6ZXJvLg0KPiA+ID4gPiA+DQo+ID4gPiA+
ID4gQlRXLCBkaXZfdTY0KCkgaGFuZGxlIHRoZSBjYXNlIHdoZXJlIGRpdmlkZXIgaXMgemVyby4N
Cj4gPiA+DQo+ID4gPiBIb3c/ICBXaGVuIEkgY2hlY2tlZCB5ZXN0ZXJkYXkgaXQgbG9va2VkIGxp
a2UgZGl2X3U2NCgpIG1hcHBlZCB0byBhDQo+ID4gPiBoYXJkd2FyZSBkaXZpc2lvbiBvbiA2NC1i
aXQgdGFyZ2V0cy4gIEluIGFueSBjYXNlIGl0J3Mgbm90IGdvb2QgdG8NCj4gPiA+IHJlbHkgb24g
c3VjaCBiZWhhdmlvci4NCj4gPiA+DQo+ID4gPiA+IGN5Y2xlID0gZGl2X3U2NChucywgMTAwMCAv
IHRiX3RpY2tzX3Blcl91c2VjKTsgRm9yIHRoaXMsIEkgdGhpbmsNCj4gPiA+ID4gd2Ugd2VyZSBk
aXNjdXNzaW5nIHRoZSB0d28gaXNzdWVzOg0KPiA+ID4gPg0KPiA+ID4gPiAxLiBTY290dCB0YWxr
aW5nIGFib3V0LCB3aGVuIHRoZSB0Yl90aWNrc19wZXJfdXNlYyBpcyBhIHplcm8uDQo+ID4gPg0K
PiA+ID4gTm8gSSB3YXNuJ3QuICBJIHdhcyB0YWxraW5nIGFib3V0IHdoZW4gdGJfdGlja3NfcGVy
X3VzZWMgPiAxMDAwLCBhbmQNCj4gPiA+IHRodXMNCj4gPiA+ICIxMDAwIC8gdGJfdGlja3NfcGVy
X3VzZWMiIGlzIHplcm8uICBZb3Ugc2FpZCB0aGF0IHRoZSByZXN1bHQgd291bGQNCj4gPiA+IGJl
IG5zIGluIHRoYXQgY2FzZS4NCj4gPiA+DQo+ID4gPiA+IDIuIFlvdSBhcmUgdGFsa2luZyBhYm91
dCAxMDAwL3RiX3RpY2tzX3Blcl91c2VjIGlzIGEgemVyby4NCj4gPiA+ID4gVGhpcyBzaXR1YXRp
b24gaXMgYWJvdXQgVEIgZnJlcSA+IDFHSFouDQo+ID4gPiA+DQo+ID4gPiA+IEkgd2lsbCBmaXgg
dGhpcyBpc3N1ZS4gTGlrZSBJIHNhaWQgYmVmb3JlLCAiSWYgdGltZWJhc2UgZnJlcXVlbmN5DQo+
ID4gPiA+ID4gMUdIeiwgdGhpcyBzaG91bGQgYmUgInRiX3RpY2tzX3Blcl91c2VjIC8gMTAwMCIg
YW5kIHRvIGdldA0KPiA+ID4gdGJfdGlja3NfcGVyX25zZWMuDQo+ID4gPiA+IFRoaXMgc2hvdWxk
IGJlIGNoYW5nZWQgdG8gImN5Y2xlID0gbnMgKiB0Yl90aWNrc19wZXJfbnNlYzsiIg0KPiA+ID4g
Pg0KPiA+ID4gPiAjZGVmaW5lIFRCX0ZSRVFfMUdIWgkxMDAwDQo+ID4gPiA+DQo+ID4gPiA+IElm
ICh0Yl90aWNrc19wZXJfdXNlYyA+IFRCX0ZSRVFfMUdIWikNCj4gPiA+ID4gCWN5Y2xlID0gbnMg
KiAodGJfdGlja3NfcGVyX3VzZWMgLyAxMDAwKTsgZWxzZQ0KPiA+ID4gPiAJY3ljbGUgPSBkaXZf
dTY0KG5zLCAxMDAwIC8gdGJfdGlja3NfcGVyX3VzZWMpOw0KPiA+ID4gPg0KPiA+ID4gPiBob3cg
YWJvdXQgdGhpcz8gOikNCj4gPiA+DQo+ID4gPiBJIHN1Z2dlc3RlZCBhbiBhbHRlcm5hdGl2ZSB0
byBzYXRpc2Z5IHlvdXIgY29tcGxhaW50IHRoYXQgaXQncyBoYXJkDQo+ID4gPiB0byB0ZXN0IG9u
ZSBvZiB0aG9zZSBpZi9lbHNlIGJyYW5jaGVzLg0KPiA+ID4NCj4gPiA+IFBsdXMsIHlvdXIgdmVy
c2lvbiB3aWxsIGJlIHF1aXRlIGluYWNjdXJhdGUgaWYgKGUuZy4pDQo+ID4gPiB0Yl90aWNrc19w
ZXJfdXNlYyBpcyA1MDEsIG9yIDE5OTkuDQo+ID4gPg0KPiA+IGN5Y2xlID0gZGl2X3U2NChucyAq
IHRiX3RpY2tzX3Blcl91c2VjLCAxMDAwKTsgSXQncyBsb29rIGdvb2QuDQo+ID4gQnV0IHdoeSB3
ZSBuZWVkOg0KPiA+IAlpZiAobnMgPj0gMTAwMDApDQo+ID4gCQljeWNsZSA9ICgobnMgKyA1MDAp
IC8gMTAwMCkgKiB0Yl90aWNrc19wZXJfdXNlYzsgPw0KPiA+DQo+ID4gSSB0aGluayAiY3ljbGUg
PSBkaXZfdTY0KG5zICogdGJfdGlja3NfcGVyX3VzZWMsIDEwMDApIiBpcyBnb29kDQo+ID4gZW5v
dWdoLiA6KQ0KPiANCj4gSXQncyB0byBkZWFsIHdpdGggb3ZlcmZsb3cgaWYgYSB2ZXJ5IGxhcmdl
IHZhbHVlIG9mIG5zIGlzIHByb3ZpZGVkDQo+IChhbmQvb3IgdGJfdGlja3NfcGVyX3VzZWMgaXMg
bGFyZ2VyIHRoYW4gd2UgZXhwZWN0KS4NCj4gDQo6KSwgYXMgSSB0aGluaywgaXQncyB0byBkZWFs
IHdpdGggb3ZlcmZsb3cuIEJ1dCB5b3UgdmVyc2lvbiBjYW5ub3QgZG8gZGVhbCB3aXRoIGl0Lg0K
QmVjYXVzZSBucyBpcyB1NjQsIGlmIG5zID4gMHhmZmZmZmZmZl9mZmZmZmUwYiwgbnMgKyA1MDAg
d2lsbCBvdmVyZmxvdywgQW5kIGlmIHRiX3RpY2tzX3Blcl91c2VjID4gMTAwMCBhbmQgbnMgPiAo
MHhmZmZmZmZmZl9mZmZmZmZmZiAvIDEwKSBjeWNsZSBhbHNvIHdpbGwgb3ZlcmZsb3cuDQoNCkkg
dGhpbmsgd2UgbmVlZCB0byBkbyB0aGlzOg0KDQojZGVmaW5lIFU2NF9MT1dfTUFTSyAgICAgICAg
ICAgIDB4ZmZmZmZmZmZVTEwNCiNkZWZpbmUgVTY0X01BU0sgICAgICAgICAgICAgICAgMHhmZmZm
ZmZmZmZmZmZmZmZmVUxMDQoNCiAgICAgICAgdTMyIHRtcF9yZW07DQogICAgICAgIHU2NCBuc191
X3JlbSwgbnNfdSwgbnNfbCwgbnNfbF9jYXJyeTsNCiAgICAgICAgdTY0IGN5Y2xlOw0KDQogICAg
ICAgIG5zX3UgPSBucyA+PiAzMjsNCiAgICAgICAgbnNfbCA9IG5zICYgVTY0X0xPV19NQVNLOw0K
DQogICAgICAgIG5zX2wgKj0gdGJfdGlja3NfcGVyX3VzZWM7DQogICAgICAgIG5zX2xfY2Fycnkg
PSBuc19sID4+IDMyOw0KICAgICAgICBuc191ICo9IHRiX3RpY2tzX3Blcl91c2VjOw0KICAgICAg
ICBuc191ICs9IG5zX2xfY2Fycnk7DQoNCiAgICAgICAgbnNfdSA9IGRpdl91NjRfcmVtKG5zX3Us
IDEwMDAsICZ0bXBfcmVtKTsNCiAgICAgICAgbnNfdV9yZW0gPSB0bXBfcmVtOw0KICAgICAgICBu
c19sID0gKG5zX2wgJiBVNjRfTE9XX01BU0spIHwgKChuc191X3JlbSkgPDwgMzIpOw0KICAgICAg
ICBuc19sID0gZGl2X3U2NChuc19sLCAxMDAwKTsNCg0KICAgICAgICBpZiAobnNfdSA+PiAzMikN
CiAgICAgICAgICAgICAgICBjeWNsZSA9IFU2NF9NQVNLOw0KICAgICAgICBlbHNlDQogICAgICAg
ICAgICAgICAgY3ljbGUgPSAobnNfdSA8PCAzMikgfCAobnNfbCAmIFU2NF9MT1dfTUFTSyk7DQoN
CkkgaGFzIGFscmVhZHkgdGVzdGVkIHRoaXMgY29kZSwgYW5kIHdvcmtzIGdvb2QuIDopDQoNCj4g
LVNjb3R0DQo+IA0KDQo=
^ permalink raw reply
* RE: [PATCH] powerpc/p1010rdb:update dts to adapt to both old and new p1010rdb
From: Zhao Qiang-B45475 @ 2013-09-29 2:29 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: Liu Shengzhou-B36685, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1380317704.24959.491.camel@snotra.buserror.net>
T24gU2F0LCAyMDEzLTA5LTI4IGF0IDU6MzUgQU0sIFNjb3R0IHdyb3RlOg0KDQo+IC0tLS0tT3Jp
Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFdvb2QgU2NvdHQtQjA3NDIxDQo+IFNlbnQ6IFNh
dHVyZGF5LCBTZXB0ZW1iZXIgMjgsIDIwMTMgNTozNSBBTQ0KPiBUbzogWmhhbyBRaWFuZy1CNDU0
NzUNCj4gQ2M6IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOyBMaXUgU2hlbmd6aG91LUIz
NjY4NQ0KPiBTdWJqZWN0OiBSZTogW1BBVENIXSBwb3dlcnBjL3AxMDEwcmRiOnVwZGF0ZSBkdHMg
dG8gYWRhcHQgdG8gYm90aCBvbGQgYW5kDQo+IG5ldyBwMTAxMHJkYg0KPiANCj4gT24gU3VuLCAy
MDEzLTA5LTIyIGF0IDEwOjI4ICswODAwLCBaaGFvIFFpYW5nIHdyb3RlOg0KPiA+IFAxMDEwcmRi
LXBhIGFuZCBwMTAxMHJkYi1wYiBoYXZlIGRpZmZlcmVudCBwaHkgaW50ZXJydXB0cy4NCj4gPiBT
byB1cGRhdGUgZHRzIHRvIGFkYXB0IHRvIGJvdGggcDEwMTByZGItcGEgYW5kIHAxMDEwcmRiLXBi
Lg0KPiA+DQo+ID4gU2lnbmVkLW9mZi1ieTogU2hlbmd6aG91IExpdSA8U2hlbmd6aG91LkxpdUBm
cmVlc2NhbGUuY29tPg0KPiA+IFNpZ25lZC1vZmYtYnk6IFpoYW8gUWlhbmcgPEI0NTQ3NUBmcmVl
c2NhbGUuY29tPg0KPiA+IC0tLQ0KPiA+ICBhcmNoL3Bvd2VycGMvYm9vdC9kdHMvcDEwMTByZGIt
cGEuZHRzIHwgMzMgKysrKysrKysrKysrKysrKysrDQo+ID4gYXJjaC9wb3dlcnBjL2Jvb3QvZHRz
L3AxMDEwcmRiLXBiLmR0cyB8IDMzICsrKysrKysrKysrKysrKysrKw0KPiA+ICBhcmNoL3Bvd2Vy
cGMvYm9vdC9kdHMvcDEwMTByZGIuZHRzICAgIHwgNjYgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tDQo+IC0tLS0tLS0tDQo+ID4gIGFyY2gvcG93ZXJwYy9ib290L2R0cy9wMTAxMHJkYi5kdHNp
ICAgfCA1MSArKysrKysrKysrKysrKysrKysrKysrKystLS0NCj4gPiAgNCBmaWxlcyBjaGFuZ2Vk
LCAxMTIgaW5zZXJ0aW9ucygrKSwgNzEgZGVsZXRpb25zKC0pICBjcmVhdGUgbW9kZQ0KPiA+IDEw
MDY0NCBhcmNoL3Bvd2VycGMvYm9vdC9kdHMvcDEwMTByZGItcGEuZHRzDQo+ID4gIGNyZWF0ZSBt
b2RlIDEwMDY0NCBhcmNoL3Bvd2VycGMvYm9vdC9kdHMvcDEwMTByZGItcGIuZHRzDQo+ID4gIGRl
bGV0ZSBtb2RlIDEwMDY0NCBhcmNoL3Bvd2VycGMvYm9vdC9kdHMvcDEwMTByZGIuZHRzDQo+IA0K
PiBXaGF0IGFib3V0IHAxMDEwcmRiXzM2Yi5kdHM/DQo+IA0KPiAtU2NvdHQNCj4gDQoNClllcywg
d2UgcmVhbGx5IG5lZWQgdG8gdGFrZSAzNmIgaW50byBhY2NvdW50Lg0KTm93LCB0aGVyZSBpcyBh
bm90aGVyIHByb2JsZW0gdG8gYmUgZGlzY3Vzc2VkLg0KSWYgd2UganVzdCBhZGQgZmlsZXMgcDEw
MTByZGItcGIuZHRzIGFuZCBwMTAxMHJkYi1wYl8zNmIuZHRzLCB0aGVyZSB3aWxsIGJlIHNvbWUg
cmVkdW5kYW50IGNvZGVzLg0KSWYgd2Ugd2FudCB0byBhdm9pZCB0aGlzIHNpdHVhdGlvbiwgd2Ug
bmVlZCB0byBhZGQgdHdvIG1vcmUgZHRzaSBmaWxlcy4NCkxlc3MgY29kZXMgb3IgbGVzcyBmaWxl
cywgd2hpY2ggb25lIGRvIHlvdSBsaWtlIGJldHRlcj8NCg0KLVpoYW8gUWlhbmcNCg==
^ permalink raw reply
* Re: Please revert 928bea964827d7824b548c1f8e06eccbbc4d0d7d
From: Rafael J. Wysocki @ 2013-09-29 0:40 UTC (permalink / raw)
To: Yinghai Lu
Cc: linuxppc-dev, Linux Kernel list, linux-pci@vger.kernel.org,
Bjorn Helgaas, Linus Torvalds
In-Reply-To: <CAE9FiQV8ipnQ_vV68S-QHMrUrQTWQT_XObxyBeR=dOuw6fG1eg@mail.gmail.com>
On Friday, September 27, 2013 04:44:20 PM Yinghai Lu wrote:
> [+ Rafael]
>
> On Fri, Sep 27, 2013 at 4:19 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > On Fri, 2013-09-27 at 15:56 -0700, Yinghai Lu wrote:
> >
> >> ok, please if you are ok attached one instead. It will print some warning about
> >> driver skipping pci_set_master, so we can catch more problem with drivers.
> >
> > Except that the message is pretty cryptic :-) Especially since the
> > driver causing the message to be printed is not the one that did
> > the mistake in the first place, it's the next one coming up that
> > trips the warning.
> >
> > In any case, the root cause is indeed the PCIe port driver:
> >
> > We don't have ACPI, so pcie_port_platform_notify() isn't implemented,
> > and pcie_ports_auto is true, so we end up with capabilities set to 0.
>
> in
> | commit fe31e69740eddc7316071ed5165fed6703c8cd12
> | Author: Rafael J. Wysocki <rjw@sisk.pl>
> | Date: Sun Dec 19 15:57:16 2010 +0100
> |
> | PCI/PCIe: Clear Root PME Status bits early during system resume
> |
> | I noticed that PCI Express PMEs don't work on my Toshiba Portege R500
> | after the system has been woken up from a sleep state by a PME
> | (through Wake-on-LAN). After some investigation it turned out that
> | the BIOS didn't clear the Root PME Status bit in the root port that
> | received the wakeup PME and since the Requester ID was also set in
> | the port's Root Status register, any subsequent PMEs didn't trigger
> | interrupts.
> |
> | This problem can be avoided by clearing the Root PME Status bits in
> | all PCI Express root ports during early resume. For this purpose,
> | add an early resume routine to the PCIe port driver and make this
> | driver be always registered, even if pci_ports_disable is set (in
> | which case the driver's only function is to provide the early
> | resume callback).
> |
> |
> |@@ -349,15 +349,18 @@ int pcie_port_device_register(struct pci_dev *dev)
> | int status, capabilities, i, nr_service;
> | int irqs[PCIE_PORT_DEVICE_MAXSERVICES];
> |
> |- /* Get and check PCI Express port services */
> |- capabilities = get_port_device_capability(dev);
> |- if (!capabilities)
> |- return -ENODEV;
> |-
> | /* Enable PCI Express port device */
> | status = pci_enable_device(dev);
> | if (status)
> | return status;
> |+
> |+ /* Get and check PCI Express port services */
> |+ capabilities = get_port_device_capability(dev);
> |+ if (!capabilities) {
> |+ pcie_no_aspm();
> |+ return 0;
> |+ }
> |+
> | pci_set_master(dev);
> | /*
> | * Initialize service irqs. Don't use service devices that
>
> >
> > Thus the port driver bails out before calling pci_set_master(). The fix
> > is to call pci_set_master() unconditionally. However that lead me to
> > find to a few interesting oddities in that port driver code:
>
> can we revert that partially change ? aka we should check get_port....
> at first...
>
> like attached.
It looks like we can do something like this (just pasting your patch):
diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
index 31063ac..1ee6f16 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
@@ -362,16 +362,16 @@ int pcie_port_device_register(struct pci_dev *dev)
int status, capabilities, i, nr_service;
int irqs[PCIE_PORT_DEVICE_MAXSERVICES];
- /* Enable PCI Express port device */
- status = pci_enable_device(dev);
- if (status)
- return status;
-
/* Get and check PCI Express port services */
capabilities = get_port_device_capability(dev);
if (!capabilities)
return 0;
+ /* Enable PCI Express port device */
+ status = pci_enable_device(dev);
+ if (status)
+ return status;
+
pci_set_master(dev);
/*
* Initialize service irqs. Don't use service devices that
but I don't have that box with me to test whether or not it still works
correctly after this change. I'll be back home on the next Saturday if
all goes well.
Thanks,
Rafael
^ permalink raw reply related
* Re: Please revert 928bea964827d7824b548c1f8e06eccbbc4d0d7d
From: Yinghai Lu @ 2013-09-28 20:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-pci@vger.kernel.org, linuxppc-dev, Linux Kernel list,
Rafael J. Wysocki, Bjorn Helgaas, Linus Torvalds
In-Reply-To: <1380337550.27811.71.camel@pasglop>
On Fri, Sep 27, 2013 at 8:05 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Fri, 2013-09-27 at 16:44 -0700, Yinghai Lu wrote:
>
> In the meantime, can you properly submit the other one with the warning
> to Linus ? It will make things more robust overall...
https://patchwork.kernel.org/patch/2959121/
^ permalink raw reply
* Re: [RFC PATCH 09/11] kvm: simplify processor compat check
From: Aneesh Kumar K.V @ 2013-09-28 15:36 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Gleb Natapov, <kvm@vger.kernel.org> list, Alexander Graf,
kvm-ppc, Paul Mackerras, linuxppc-dev
In-Reply-To: <5245A0DD.9070205@redhat.com>
Paolo Bonzini <pbonzini@redhat.com> writes:
> Il 27/09/2013 15:13, Aneesh Kumar K.V ha scritto:
>> Alexander Graf <agraf@suse.de> writes:
>>
>>> On 27.09.2013, at 12:03, Aneesh Kumar K.V wrote:
>>>
>>>> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>>>
>>> Missing patch description.
>>>
>>>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>>>
>>> I fail to see how this really simplifies things, but at the end of the
>>> day it's Gleb's and Paolo's call.
>>
>> will do. It avoid calling
>>
>> for_each_online_cpu(cpu) {
>> smp_call_function_single()
>>
>> on multiple architecture.
>
> I agree with Alex.
>
> The current code is not specially awesome; having
> kvm_arch_check_processor_compat take an int* disguised as a void* is a
> bit ugly indeed.
>
> However, the API makes sense and tells you that it is being passed as a
> callback (to smp_call_function_single in this case).
But whether to check on all cpus or not is arch dependent right?.
IIUC only x86 and ppc64 need to do that. Also on ppc64 it really
depends on whether HV or PR. We need to check on all cpus only if it is
HV.
>
> You are making the API more complicated to use on the arch layer
> (because arch maintainers now have to think "do I need to check this on
> all online CPUs?") and making the "leaf" POWER code less legible because
> it still has the weird void()(void *) calling convention.
>
IIUC what we wanted to check is to find out whether kvm can run on this
system. That is really an arch specific check. So for core kvm the call
should be a simple
if (kvm_arch_check_process_compat() < 0)
error;
Now how each arch figure out whether kvm can run on this system should
be arch specific. For x86 we do need to check all the cpus. On ppc64 for
HV we need to. For other archs we always allow kvm.
> If anything, you could change kvm_arch_check_processor_compat to return
> an int and accept no argument, and introduce a wrapper that kvm_init
> passes to smp_call_function_single.
What i am suggesting in the patch is to avoid calling
smp_call_function_single from kvm_init and let arch decide whether to
check on all cpus or not.
-aneesh
^ permalink raw reply
* [PATCH v2 2/2] ppc: bpf_jit: support MOD operation
From: Vladimir Murzin @ 2013-09-28 8:22 UTC (permalink / raw)
To: linuxppc-dev
Cc: matt, netdev, Vladimir Murzin, dborkman, edumazet, paulus, davem
In-Reply-To: <1380356521-3432-1-git-send-email-murzin.v@gmail.com>
commit b6069a9570 (filter: add MOD operation) added generic
support for modulus operation in BPF.
This patch brings JIT support for PPC64
Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
Acked-by: Matt Evans <matt@ozlabs.org>
---
Changelog
v1->v2
Definition for r_scratch2 was moved to header file.
arch/powerpc/net/bpf_jit.h | 1 +
arch/powerpc/net/bpf_jit_comp.c | 20 ++++++++++++++++++++
2 files changed, 21 insertions(+)
diff --git a/arch/powerpc/net/bpf_jit.h b/arch/powerpc/net/bpf_jit.h
index 8a5dfaf..42a115a 100644
--- a/arch/powerpc/net/bpf_jit.h
+++ b/arch/powerpc/net/bpf_jit.h
@@ -39,6 +39,7 @@
#define r_X 5
#define r_addr 6
#define r_scratch1 7
+#define r_scratch2 8
#define r_D 14
#define r_HL 15
#define r_M 16
diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
index bf56e33..cbb2702 100644
--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -193,6 +193,26 @@ static int bpf_jit_build_body(struct sk_filter *fp, u32 *image,
PPC_MUL(r_A, r_A, r_scratch1);
}
break;
+ case BPF_S_ALU_MOD_X: /* A %= X; */
+ ctx->seen |= SEEN_XREG;
+ PPC_CMPWI(r_X, 0);
+ if (ctx->pc_ret0 != -1) {
+ PPC_BCC(COND_EQ, addrs[ctx->pc_ret0]);
+ } else {
+ PPC_BCC_SHORT(COND_NE, (ctx->idx*4)+12);
+ PPC_LI(r_ret, 0);
+ PPC_JMP(exit_addr);
+ }
+ PPC_DIVWU(r_scratch1, r_A, r_X);
+ PPC_MUL(r_scratch1, r_X, r_scratch1);
+ PPC_SUB(r_A, r_A, r_scratch1);
+ break;
+ case BPF_S_ALU_MOD_K: /* A %= K; */
+ PPC_LI32(r_scratch2, K);
+ PPC_DIVWU(r_scratch1, r_A, r_scratch2);
+ PPC_MUL(r_scratch1, r_scratch2, r_scratch1);
+ PPC_SUB(r_A, r_A, r_scratch1);
+ break;
case BPF_S_ALU_DIV_X: /* A /= X; */
ctx->seen |= SEEN_XREG;
PPC_CMPWI(r_X, 0);
--
1.8.1.5
^ permalink raw reply related
* [PATCH v2 1/2] powerpc: net: filter: fix DIVWU instruction opcode
From: Vladimir Murzin @ 2013-09-28 8:22 UTC (permalink / raw)
To: linuxppc-dev
Cc: matt, netdev, Vladimir Murzin, dborkman, edumazet, paulus, davem
Currently DIVWU stands for *signed* divw opcode:
7d 2a 4b 96 divwu r9,r10,r9
7d 2a 4b d6 divw r9,r10,r9
Use the *unsigned* divw opcode for DIVWU.
Suggested-by: Vassili Karpov <av1474@comtv.ru>
Reviewed-by: Vassili Karpov <av1474@comtv.ru>
Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
Acked-by: Matt Evans <matt@ozlabs.org>
---
Changelog
v1->v2
Added credit to Vassili Karpov (malc) who kindly reviewed generated assembly
[1] and highlighted usage of signed division.
Note: temporary, for technical reason, he's not able to receive email.
[1]http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg71635.html
arch/powerpc/include/asm/ppc-opcode.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h
index eccfc16..0a4a683 100644
--- a/arch/powerpc/include/asm/ppc-opcode.h
+++ b/arch/powerpc/include/asm/ppc-opcode.h
@@ -171,7 +171,7 @@
#define PPC_INST_MULLW 0x7c0001d6
#define PPC_INST_MULHWU 0x7c000016
#define PPC_INST_MULLI 0x1c000000
-#define PPC_INST_DIVWU 0x7c0003d6
+#define PPC_INST_DIVWU 0x7c000396
#define PPC_INST_RLWINM 0x54000000
#define PPC_INST_RLDICR 0x78000004
#define PPC_INST_SLW 0x7c000030
--
1.8.1.5
^ permalink raw reply related
* Re: Please revert 928bea964827d7824b548c1f8e06eccbbc4d0d7d
From: Benjamin Herrenschmidt @ 2013-09-28 3:05 UTC (permalink / raw)
To: Yinghai Lu
Cc: linux-pci@vger.kernel.org, linuxppc-dev, Linux Kernel list,
Rafael J. Wysocki, Bjorn Helgaas, Linus Torvalds
In-Reply-To: <CAE9FiQV8ipnQ_vV68S-QHMrUrQTWQT_XObxyBeR=dOuw6fG1eg@mail.gmail.com>
On Fri, 2013-09-27 at 16:44 -0700, Yinghai Lu wrote:
> > Thus the port driver bails out before calling pci_set_master(). The fix
> > is to call pci_set_master() unconditionally. However that lead me to
> > find to a few interesting oddities in that port driver code:
>
> can we revert that partially change ? aka we should check get_port....
> at first...
>
> like attached.
In the meantime, can you properly submit the other one with the warning
to Linus ? It will make things more robust overall...
Also, please read my other comments. I think we are treading on very
fragile ground with that whole business of potentially disabling bridges
in the pcieport driver ...
Cheers,
Ben.
^ permalink raw reply
* Re: Please revert 928bea964827d7824b548c1f8e06eccbbc4d0d7d
From: Yinghai Lu @ 2013-09-27 23:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-pci@vger.kernel.org, linuxppc-dev, Linux Kernel list,
Rafael J. Wysocki, Bjorn Helgaas, Linus Torvalds
In-Reply-To: <1380323960.27811.67.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 2949 bytes --]
[+ Rafael]
On Fri, Sep 27, 2013 at 4:19 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Fri, 2013-09-27 at 15:56 -0700, Yinghai Lu wrote:
>
>> ok, please if you are ok attached one instead. It will print some warning about
>> driver skipping pci_set_master, so we can catch more problem with drivers.
>
> Except that the message is pretty cryptic :-) Especially since the
> driver causing the message to be printed is not the one that did
> the mistake in the first place, it's the next one coming up that
> trips the warning.
>
> In any case, the root cause is indeed the PCIe port driver:
>
> We don't have ACPI, so pcie_port_platform_notify() isn't implemented,
> and pcie_ports_auto is true, so we end up with capabilities set to 0.
in
| commit fe31e69740eddc7316071ed5165fed6703c8cd12
| Author: Rafael J. Wysocki <rjw@sisk.pl>
| Date: Sun Dec 19 15:57:16 2010 +0100
|
| PCI/PCIe: Clear Root PME Status bits early during system resume
|
| I noticed that PCI Express PMEs don't work on my Toshiba Portege R500
| after the system has been woken up from a sleep state by a PME
| (through Wake-on-LAN). After some investigation it turned out that
| the BIOS didn't clear the Root PME Status bit in the root port that
| received the wakeup PME and since the Requester ID was also set in
| the port's Root Status register, any subsequent PMEs didn't trigger
| interrupts.
|
| This problem can be avoided by clearing the Root PME Status bits in
| all PCI Express root ports during early resume. For this purpose,
| add an early resume routine to the PCIe port driver and make this
| driver be always registered, even if pci_ports_disable is set (in
| which case the driver's only function is to provide the early
| resume callback).
|
|
|@@ -349,15 +349,18 @@ int pcie_port_device_register(struct pci_dev *dev)
| int status, capabilities, i, nr_service;
| int irqs[PCIE_PORT_DEVICE_MAXSERVICES];
|
|- /* Get and check PCI Express port services */
|- capabilities = get_port_device_capability(dev);
|- if (!capabilities)
|- return -ENODEV;
|-
| /* Enable PCI Express port device */
| status = pci_enable_device(dev);
| if (status)
| return status;
|+
|+ /* Get and check PCI Express port services */
|+ capabilities = get_port_device_capability(dev);
|+ if (!capabilities) {
|+ pcie_no_aspm();
|+ return 0;
|+ }
|+
| pci_set_master(dev);
| /*
| * Initialize service irqs. Don't use service devices that
>
> Thus the port driver bails out before calling pci_set_master(). The fix
> is to call pci_set_master() unconditionally. However that lead me to
> find to a few interesting oddities in that port driver code:
can we revert that partially change ? aka we should check get_port....
at first...
like attached.
Thanks
Yinghai
[-- Attachment #2: fix_pci_set_master_port_pcie.patch --]
[-- Type: application/octet-stream, Size: 784 bytes --]
diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
index 31063ac..1ee6f16 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
@@ -362,16 +362,16 @@ int pcie_port_device_register(struct pci_dev *dev)
int status, capabilities, i, nr_service;
int irqs[PCIE_PORT_DEVICE_MAXSERVICES];
- /* Enable PCI Express port device */
- status = pci_enable_device(dev);
- if (status)
- return status;
-
/* Get and check PCI Express port services */
capabilities = get_port_device_capability(dev);
if (!capabilities)
return 0;
+ /* Enable PCI Express port device */
+ status = pci_enable_device(dev);
+ if (status)
+ return status;
+
pci_set_master(dev);
/*
* Initialize service irqs. Don't use service devices that
^ permalink raw reply related
* Re: Please revert 928bea964827d7824b548c1f8e06eccbbc4d0d7d
From: Benjamin Herrenschmidt @ 2013-09-27 23:19 UTC (permalink / raw)
To: Yinghai Lu
Cc: Bjorn Helgaas, linux-pci@vger.kernel.org, Linus Torvalds,
linuxppc-dev, Linux Kernel list
In-Reply-To: <CAE9FiQWm7ALPO5k_2nV+fuZw4oNNiw+_PEx8EWkb52ymN+EYUg@mail.gmail.com>
On Fri, 2013-09-27 at 15:56 -0700, Yinghai Lu wrote:
> ok, please if you are ok attached one instead. It will print some warning about
> driver skipping pci_set_master, so we can catch more problem with drivers.
Except that the message is pretty cryptic :-) Especially since the
driver causing the message to be printed is not the one that did
the mistake in the first place, it's the next one coming up that
trips the warning.
In any case, the root cause is indeed the PCIe port driver:
We don't have ACPI, so pcie_port_platform_notify() isn't implemented,
and pcie_ports_auto is true, so we end up with capabilities set to 0.
Thus the port driver bails out before calling pci_set_master(). The fix
is to call pci_set_master() unconditionally. However that lead me to
find to a few interesting oddities in that port driver code:
- If capabilities is 0, it returns after enabling the device and
doesn't disable it. But if it fails for any other reason later on (such
as failing to enable interrupts), it *will* disable the device. This is
inconsistent. In fact, if it had disabled the device as a result of the
0 capabilities, the problem would also not have happened (the subsequent
enable_bridge done by the e1000e driver would have done the right
thing). I've tested "fixing" that instead of moving the set_master call
and it fixes my problem as well.
- In get_port_device_capability(), all capabilities are gated by a
combination of the bit in cap_mask and a corresponding HW check of
the presence of the relevant PCIe capability or similar... except
for the VC one, which is solely read from the HW capability. That means
that the platform pcie_port_platform_notify() has no ability to prevent
the VC capability (so if I have a broken bridge that advertises it but
my platform wants to block it, it can't).
- I am quite nervous with the PCIe port driver disabling bridges. I
understand the intent but what if that bridge has some system device
behind it ? Something you don't even know about (used by ACPI, behind an
ISA bridge for example ?).
I think disabling bridges is a VERY risky proposition at all times
(including during PM) and I don't think the port driver should do it.
Maybe a more robust approach would be to detect one way or another that
the bridge was already enabled and only disable it if it wasn't or
something along those lines (ie ,restore it in the state it was)...
This is not my problem right now of course (in my case the bridge was
disabled to begin with) but I have a long experience with system stuff
hiding behind bridges and the code as it is written makes me a bit
nervous.
Cheers,
Ben.
^ permalink raw reply
* Re: Please revert 928bea964827d7824b548c1f8e06eccbbc4d0d7d
From: Yinghai Lu @ 2013-09-27 22:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Bjorn Helgaas, linux-pci@vger.kernel.org, Linus Torvalds,
linuxppc-dev, Linux Kernel list
In-Reply-To: <1380321480.27811.53.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 942 bytes --]
On Fri, Sep 27, 2013 at 3:38 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Fri, 2013-09-27 at 14:54 -0700, Yinghai Lu wrote:
>> On Fri, Sep 27, 2013 at 2:46 PM, Benjamin Herrenschmidt
>> <benh@kernel.crashing.org> wrote:
>>
>> > Wouldn't it be better to simply have pci_enable_device() always set bus
>> > master on a bridge? I don't see any case where it makes sense to have
>> > an enabled bridge without the master bit set on it...
>>
>> Do you mean attached?
>
> So this patch works and fixes the problem. I think it makes the whole
> thing more robust and should be applied.
good.
>
> I still don't know why the bridge doesn't get enabled properly without
> it yes, tracking it down (the machine in question takes a LONG time to
> reboot :-)
ok, please if you are ok attached one instead. It will print some warning about
driver skipping pci_set_master, so we can catch more problem with drivers.
Thanks
Yinghai
[-- Attachment #2: pci_set_master_again_v2.patch --]
[-- Type: application/octet-stream, Size: 1420 bytes --]
Subject: [PATCH] PCI: Workaround missing pci_set_master in pci drivers
BenH found:
| 928bea964827d7824b548c1f8e06eccbbc4d0d7d
| PCI: Delay enabling bridges until they're needed
break PCI on powerpc. The reason is that the PCIe port driver will
call pci_enable_device() on the bridge, so device enabled (but skip
pci_set_master somehow).
Because of that, pci_enable_bridge() later on (called as a result of the
child device driver doing pci_enable_device) will see the bridge as
already enabled and will not call pci_set_master() on it.
Fixed by add checking in pci_enable_bridge, and call pci_set_master
if driver skip that.
Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
---
drivers/pci/pci.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
Index: linux-2.6/drivers/pci/pci.c
===================================================================
--- linux-2.6.orig/drivers/pci/pci.c
+++ linux-2.6/drivers/pci/pci.c
@@ -1156,8 +1156,14 @@ static void pci_enable_bridge(struct pci
pci_enable_bridge(dev->bus->self);
- if (pci_is_enabled(dev))
+ if (pci_is_enabled(dev)) {
+ if (!dev->is_busmaster) {
+ dev_warn(&dev->dev, "driver skip pci_set_master, fix it!\n");
+ pci_set_master(dev);
+ }
return;
+ }
+
retval = pci_enable_device(dev);
if (retval)
dev_err(&dev->dev, "Error enabling bridge (%d), continuing\n",
^ permalink raw reply
* Re: Please revert 928bea964827d7824b548c1f8e06eccbbc4d0d7d
From: Benjamin Herrenschmidt @ 2013-09-27 22:38 UTC (permalink / raw)
To: Yinghai Lu
Cc: Bjorn Helgaas, linux-pci@vger.kernel.org, Linus Torvalds,
linuxppc-dev, Linux Kernel list
In-Reply-To: <CAE9FiQXXvkfTak6oEpUog_RYs_Gwpdji7N5UJ=R11Q61==N97A@mail.gmail.com>
On Fri, 2013-09-27 at 14:54 -0700, Yinghai Lu wrote:
> On Fri, Sep 27, 2013 at 2:46 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
>
> > Wouldn't it be better to simply have pci_enable_device() always set bus
> > master on a bridge? I don't see any case where it makes sense to have
> > an enabled bridge without the master bit set on it...
>
> Do you mean attached?
So this patch works and fixes the problem. I think it makes the whole
thing more robust and should be applied.
I still don't know why the bridge doesn't get enabled properly without
it yes, tracking it down (the machine in question takes a LONG time to
reboot :-)
Cheers,
Ben.
^ permalink raw reply
* Re: Please revert 928bea964827d7824b548c1f8e06eccbbc4d0d7d
From: Benjamin Herrenschmidt @ 2013-09-27 22:15 UTC (permalink / raw)
To: Yinghai Lu
Cc: Bjorn Helgaas, linux-pci@vger.kernel.org, Linus Torvalds,
linuxppc-dev, Linux Kernel list
In-Reply-To: <CAE9FiQW+b7OtN4hJc6uygzbqzaCOkn3WcLDgSg5isHAJfdgmwg@mail.gmail.com>
On Fri, 2013-09-27 at 10:44 -0700, Yinghai Lu wrote:
> | /* Get and check PCI Express port services */
> | capabilities = get_port_device_capability(dev);
> | if (!capabilities)
> | return 0;
> |
> | pci_set_master(dev);
>
> so how come that pci_set_master is not called for powerpc?
>
> Can you send out lspci -vvxxx with current linus-tree and v3.11?
Ah good point. It should have ... except that there are a number of ways
for get_port_device_capability() to fail and that should *not* leave the
bridge without the bus master capability set.
However I don't think that's what's happening here. I'll have to dig
more, will get back to you.
Cheers,
Ben.
^ permalink raw reply
* Re: Please revert 928bea964827d7824b548c1f8e06eccbbc4d0d7d
From: Benjamin Herrenschmidt @ 2013-09-27 22:00 UTC (permalink / raw)
To: Yinghai Lu
Cc: Bjorn Helgaas, linux-pci@vger.kernel.org, Linus Torvalds,
linuxppc-dev, Linux Kernel list
In-Reply-To: <CAE9FiQXXvkfTak6oEpUog_RYs_Gwpdji7N5UJ=R11Q61==N97A@mail.gmail.com>
On Fri, 2013-09-27 at 14:54 -0700, Yinghai Lu wrote:
> On Fri, Sep 27, 2013 at 2:46 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
>
> > Wouldn't it be better to simply have pci_enable_device() always set bus
> > master on a bridge? I don't see any case where it makes sense to have
> > an enabled bridge without the master bit set on it...
>
> Do you mean attached?
That's an option. I was thinking making pci_enable_device() itself
enable bus master on a bridge but yes, you approach should work.
I'm digging a bit more to figure out what went wrong in the
pcie port driver since that's interesting in its own right and I'll then
test your patch which I think is a more robust approach.
Cheers,
Ben.
^ permalink raw reply
* Re: Please revert 928bea964827d7824b548c1f8e06eccbbc4d0d7d
From: Yinghai Lu @ 2013-09-27 21:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Bjorn Helgaas, linux-pci@vger.kernel.org, Linus Torvalds,
linuxppc-dev, Linux Kernel list
In-Reply-To: <1380318405.27811.37.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 316 bytes --]
On Fri, Sep 27, 2013 at 2:46 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> Wouldn't it be better to simply have pci_enable_device() always set bus
> master on a bridge? I don't see any case where it makes sense to have
> an enabled bridge without the master bit set on it...
Do you mean attached?
[-- Attachment #2: pci_set_master_again.patch --]
[-- Type: application/octet-stream, Size: 510 bytes --]
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index e8ccf6c..4eff99b 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1156,11 +1156,13 @@ static void pci_enable_bridge(struct pci_dev *dev)
pci_enable_bridge(dev->bus->self);
if (pci_is_enabled(dev))
- return;
+ goto out; /* some other driver could skip pci_set_master ! */
retval = pci_enable_device(dev);
if (retval)
dev_err(&dev->dev, "Error enabling bridge (%d), continuing\n",
retval);
+
+out:
pci_set_master(dev);
}
^ permalink raw reply related
* Re: Please revert 928bea964827d7824b548c1f8e06eccbbc4d0d7d
From: Benjamin Herrenschmidt @ 2013-09-27 21:46 UTC (permalink / raw)
To: Linus Torvalds
Cc: Bjorn Helgaas, linux-pci@vger.kernel.org, Yinghai Lu,
linuxppc-dev, Linux Kernel list
In-Reply-To: <CA+55aFyDfMdAeaniQwkoeW6F-xd3JxrzGYwtFb6N9+NA6aRCMg@mail.gmail.com>
On Fri, 2013-09-27 at 10:10 -0700, Linus Torvalds wrote:
> > So i would like to use the first way that you suggest : call pci_set_master
> > PCIe port driver.
>
> So I have to say, that if we can fix this with just adding a single
> new pci_set_master() call, we should do that before we decide to
> revert.
>
> If other, bigger issues then come up, we can decide to revert. But if
> there's a one-liner fix, let's just do that first, ok?
>
> Mind sending a patch?
Wouldn't it be better to simply have pci_enable_device() always set bus
master on a bridge? I don't see any case where it makes sense to have
an enabled bridge without the master bit set on it...
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v4] powerpc 8xx: Fixing issue with CONFIG_PIN_TLB
From: Scott Wood @ 2013-09-27 21:43 UTC (permalink / raw)
To: Christophe Leroy; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <201309240818.r8O8IdF9016374@localhost.localdomain>
On Tue, 2013-09-24 at 10:18 +0200, Christophe Leroy wrote:
> Activating CONFIG_PIN_TLB is supposed to pin the IMMR and the first three
> 8Mbytes pages. But the setting of MD_CTR to a pinnable entry was missing before
> the pinning of the third 8Mb page. As the index is decremented module 28
> (MD_RSV4D is set) after every DTLB update, the third 8Mbytes page was
> not pinned.
The examples you showed weren't quite modulo 28, more like "if (x >= 28)
x -= 4". I'll fix up the changelog on applying, to read something like
"As the index is decremented to a value within the first 28 entries
(MD_RSV4D is set)...".
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc/p1010rdb:update dts to adapt to both old and new p1010rdb
From: Scott Wood @ 2013-09-27 21:35 UTC (permalink / raw)
To: Zhao Qiang; +Cc: linuxppc-dev, Shengzhou Liu
In-Reply-To: <1379816919-13851-1-git-send-email-B45475@freescale.com>
On Sun, 2013-09-22 at 10:28 +0800, Zhao Qiang wrote:
> P1010rdb-pa and p1010rdb-pb have different phy interrupts.
> So update dts to adapt to both p1010rdb-pa and p1010rdb-pb.
>
> Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
> Signed-off-by: Zhao Qiang <B45475@freescale.com>
> ---
> arch/powerpc/boot/dts/p1010rdb-pa.dts | 33 ++++++++++++++++++
> arch/powerpc/boot/dts/p1010rdb-pb.dts | 33 ++++++++++++++++++
> arch/powerpc/boot/dts/p1010rdb.dts | 66 -----------------------------------
> arch/powerpc/boot/dts/p1010rdb.dtsi | 51 ++++++++++++++++++++++++---
> 4 files changed, 112 insertions(+), 71 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/p1010rdb-pa.dts
> create mode 100644 arch/powerpc/boot/dts/p1010rdb-pb.dts
> delete mode 100644 arch/powerpc/boot/dts/p1010rdb.dts
What about p1010rdb_36b.dts?
-Scott
^ permalink raw reply
* Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
From: Scott Wood @ 2013-09-27 21:33 UTC (permalink / raw)
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
Bhushan Bharat-R65777
In-Reply-To: <ABB05CD9C9F68C46A5CEDC7F15439259010911C2@039-SN2MPN1-021.039d.mgd.msft.net>
On Thu, 2013-09-26 at 22:34 -0500, Wang Dongsheng-B40534 wrote:
>
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Friday, September 27, 2013 5:37 AM
> > To: Wang Dongsheng-B40534
> > Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
> > dev@lists.ozlabs.org
> > Subject: Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and
> > altivec idle
> >
> > On Thu, 2013-09-26 at 01:18 -0500, Wang Dongsheng-B40534 wrote:
> > >
> > > > -----Original Message-----
> > > > From: Bhushan Bharat-R65777
> > > > Sent: Thursday, September 26, 2013 12:23 PM
> > > > To: Wang Dongsheng-B40534; Wood Scott-B07421
> > > > Cc: linuxppc-dev@lists.ozlabs.org
> > > > Subject: RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state
> > > > and altivec idle
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Wang Dongsheng-B40534
> > > > > Sent: Thursday, September 26, 2013 8:02 AM
> > > > > To: Wood Scott-B07421
> > > > > Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org
> > > > > Subject: RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state
> > > > > and altivec idle
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Wood Scott-B07421
> > > > > > Sent: Thursday, September 26, 2013 1:57 AM
> > > > > > To: Wang Dongsheng-B40534
> > > > > > Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
> > > > > > dev@lists.ozlabs.org
> > > > > > Subject: Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20
> > > > > > state and altivec idle
> > > > > >
> > > > > > On Wed, 2013-09-25 at 03:10 -0500, Wang Dongsheng-B40534 wrote:
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Bhushan Bharat-R65777
> > > > > > > > Sent: Wednesday, September 25, 2013 2:23 PM
> > > > > > > > To: Wang Dongsheng-B40534; Wood Scott-B07421
> > > > > > > > Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
> > > > > > > > Subject: RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20
> > > > > > > > state and altivec idle
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Linuxppc-dev [mailto:linuxppc-dev-
> > > > > > > > > bounces+bharat.bhushan=freescale.com@lists.ozlabs.org] On
> > > > > > > > > bounces+Behalf Of Dongsheng
> > > > > > > > > Wang
> > > > > > > > > Sent: Tuesday, September 24, 2013 2:59 PM
> > > > > > > > > To: Wood Scott-B07421
> > > > > > > > > Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
> > > > > > > > > Subject: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20
> > > > > > > > > state and altivec idle
> > > > > > > > >
> > > > > > > > > From: Wang Dongsheng <dongsheng.wang@freescale.com>
> > > > > > > > >
> > > > > > > > > Add a sys interface to enable/diable pw20 state or altivec
> > > > > > > > > idle, and control the wait entry time.
> > > > > > > > >
> > > > > > > > > Enable/Disable interface:
> > > > > > > > > 0, disable. 1, enable.
> > > > > > > > > /sys/devices/system/cpu/cpuX/pw20_state
> > > > > > > > > /sys/devices/system/cpu/cpuX/altivec_idle
> > > > > > > > >
> > > > > > > > > Set wait time interface:(Nanosecond)
> > > > > > > > > /sys/devices/system/cpu/cpuX/pw20_wait_time
> > > > > > > > > /sys/devices/system/cpu/cpuX/altivec_idle_wait_time
> > > > > > > > > Example: Base on TBfreq is 41MHZ.
> > > > > > > > > 1~47(ns): TB[63]
> > > > > > > > > 48~95(ns): TB[62]
> > > > > > > > > 96~191(ns): TB[61]
> > > > > > > > > 192~383(ns): TB[62]
> > > > > > > > > 384~767(ns): TB[60]
> > > > > > > > > ...
> > > > > > > > >
> > > > > > > > > Signed-off-by: Wang Dongsheng
> > > > > > > > > <dongsheng.wang@freescale.com>
> > > > > > > > > ---
> > > > > > > > > *v4:
> > > > > > > > > Move code from 85xx/common.c to kernel/sysfs.c.
> > > > > > > > >
> > > > > > > > > Remove has_pw20_altivec_idle function.
> > > > > > > > >
> > > > > > > > > Change wait "entry_bit" to wait time.
> > > > > > > > >
> > > > > > > > > arch/powerpc/kernel/sysfs.c | 291
> > > > > > > > > ++++++++++++++++++++++++++++++++++++++++++++
> > > > > > > > > 1 file changed, 291 insertions(+)
> > > > > > > > >
> > > > > > > > > diff --git a/arch/powerpc/kernel/sysfs.c
> > > > > > > > > b/arch/powerpc/kernel/sysfs.c index 27a90b9..23fece6
> > > > > > > > > 100644
> > > > > > > > > --- a/arch/powerpc/kernel/sysfs.c
> > > > > > > > > +++ b/arch/powerpc/kernel/sysfs.c
> > > > > > > > > @@ -85,6 +85,279 @@ __setup("smt-snooze-delay=",
> > > > > > > > > setup_smt_snooze_delay);
> > > > > > > > >
> > > > > > > > > #endif /* CONFIG_PPC64 */
> > > > > > > > >
> > > > > > > > > +#ifdef CONFIG_FSL_SOC
> > > > > > > > > +#define MAX_BIT 63
> > > > > > > > > +
> > > > > > > > > +static u64 pw20_wt;
> > > > > > > > > +static u64 altivec_idle_wt;
> > > > > > > > > +
> > > > > > > > > +static unsigned int get_idle_ticks_bit(u64 ns) {
> > > > > > > > > + u64 cycle;
> > > > > > > > > +
> > > > > > > > > + cycle = div_u64(ns, 1000 / tb_ticks_per_usec);
> > > > > > > >
> > > > > > > > When tb_ticks_per_usec > 1000 (timebase frequency > 1GHz)
> > > > > > > > then this will always be ns, which is not correct, no?
> > > > > >
> > > > > > Actually it'll be a divide by zero in that case.
> > > > > >
> > > > > tb_ticks_per_usec = ppc_tb_freq / 1000000; Means TB freq should be
> > > > > more than 1MHZ.
> > > > >
> > > > > if ppc_tb_freq less than 1000000, the tb_ticks_per_usec will be a
> > > > > divide by zero.
> > > > > If this condition is established, I think kernel cannot work as a
> > > > normal.
> > > > >
> > > > > So I think we need to believe that the variable is not zero.
> > > >
> > > > We do believe it is non-zero but greater than 1000 :)
> > > >
> > > > > And I think TB freq
> > > > > should not less than 1MHZ on PPC platform, because if TB freq less
> > > > > than 1MHZ, the precision time will become very poor and system
> > > > > response time will be slower.
> > > >
> > > > Not sure what you are describing here related to divide by zero we
> > > > are mentioning.
> > > > You are talking about if tb_ticks_per_usec is ZERO and we are
> > > > talking about if (1000/tb_ticks_per_usec) will be zero.
> > > >
> > > > BTW, div_u64() handle the case where divider is zero.
> >
> > How? When I checked yesterday it looked like div_u64() mapped to a
> > hardware division on 64-bit targets. In any case it's not good to rely
> > on such behavior.
> >
> > > cycle = div_u64(ns, 1000 / tb_ticks_per_usec); For this, I think we
> > > were discussing the two issues:
> > >
> > > 1. Scott talking about, when the tb_ticks_per_usec is a zero.
> >
> > No I wasn't. I was talking about when tb_ticks_per_usec > 1000, and thus
> > "1000 / tb_ticks_per_usec" is zero. You said that the result would be ns
> > in that case.
> >
> > > 2. You are talking about 1000/tb_ticks_per_usec is a zero.
> > > This situation is about TB freq > 1GHZ.
> > >
> > > I will fix this issue. Like I said before, "If timebase frequency >
> > > 1GHz, this should be "tb_ticks_per_usec / 1000" and to get
> > tb_ticks_per_nsec.
> > > This should be changed to "cycle = ns * tb_ticks_per_nsec;""
> > >
> > > #define TB_FREQ_1GHZ 1000
> > >
> > > If (tb_ticks_per_usec > TB_FREQ_1GHZ)
> > > cycle = ns * (tb_ticks_per_usec / 1000); else
> > > cycle = div_u64(ns, 1000 / tb_ticks_per_usec);
> > >
> > > how about this? :)
> >
> > I suggested an alternative to satisfy your complaint that it's hard to
> > test one of those if/else branches.
> >
> > Plus, your version will be quite inaccurate if (e.g.) tb_ticks_per_usec
> > is 501, or 1999.
> >
> cycle = div_u64(ns * tb_ticks_per_usec, 1000); It's look good.
> But why we need:
> if (ns >= 10000)
> cycle = ((ns + 500) / 1000) * tb_ticks_per_usec;
> ?
>
> I think "cycle = div_u64(ns * tb_ticks_per_usec, 1000)" is good enough. :)
It's to deal with overflow if a very large value of ns is provided
(and/or tb_ticks_per_usec is larger than we expect).
-Scott
^ permalink raw reply
* Re: Please revert 928bea964827d7824b548c1f8e06eccbbc4d0d7d
From: Yinghai Lu @ 2013-09-27 17:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Bjorn Helgaas, linux-pci@vger.kernel.org, Linus Torvalds,
linuxppc-dev, Linux Kernel list
In-Reply-To: <CAE9FiQVkW7d7vFx_kPJG-FEvO71SZjZmpR+dnwVm61wkYK=0YA@mail.gmail.com>
On Fri, Sep 27, 2013 at 9:01 AM, Yinghai Lu <yinghai@kernel.org> wrote:
> On Fri, Sep 27, 2013 at 1:28 AM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
>> Hi Linus, Yinghai !
>>
>> Please consider reverting:
>>
>> 928bea964827d7824b548c1f8e06eccbbc4d0d7d
>> PCI: Delay enabling bridges until they're needed
>>
>> (I'd suggest to revert now and maybe merge a better patch later)
>>
>> This breaks PCI on the PowerPC "powernv" platform (which is booted via
>> kexec) and probably x86 as well under similar circumstances. It will
>> basically break PCIe if the bus master bit of the bridge isn't set at
>> boot (by the firmware for example, or because kexec'ing cleared it).
>>
>> The reason is that the PCIe port driver will call pci_enable_device() on
>> the bridge (on everything under the sun actually), which will marked the
>> device enabled (but will not do a set_master).
>>
>> Because of that, pci_enable_bridge() later on (called as a result of the
>> child device driver doing pci_enable_device) will see the bridge as
>> already enabled and will not call pci_set_master() on it.
Ben,
looks like PCIe port driver does call pci_enable_device AND pci_set_master()
| int pcie_port_device_register(struct pci_dev *dev)
| {
| int status, capabilities, i, nr_service;
| int irqs[PCIE_PORT_DEVICE_MAXSERVICES];
|
| /* Enable PCI Express port device */
| status = pci_enable_device(dev);
| if (status)
| return status;
|
| /* Get and check PCI Express port services */
| capabilities = get_port_device_capability(dev);
| if (!capabilities)
| return 0;
|
| pci_set_master(dev);
so how come that pci_set_master is not called for powerpc?
Can you send out lspci -vvxxx with current linus-tree and v3.11?
Yinghai
^ permalink raw reply
* Re: [PATCH] powerpc/mpic: Disable preemption when calling mpic_processor_id()
From: Scott Wood @ 2013-09-27 17:26 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <D2DE40C4-94A5-425C-9A67-75BA6F4CD145@kernel.crashing.org>
On Fri, 2013-09-27 at 12:09 -0500, Kumar Gala wrote:
> On Sep 27, 2013, at 11:15 AM, Scott Wood wrote:
>
> > On Fri, 2013-09-27 at 10:52 -0500, Kumar Gala wrote:
> >> On Sep 26, 2013, at 7:18 PM, Scott Wood wrote:
> >>
> >>> Otherwise, we get a debug traceback due to the use of
> >>> smp_processor_id() (or get_paca()) inside hard_smp_processor_id().
> >>> mpic_host_map() is just looking for a default CPU, so it doesn't matter
> >>> if we migrate after getting the CPU ID.
> >>>
> >>> Signed-off-by: Scott Wood <scottwood@freescale.com>
> >>> ---
> >>> arch/powerpc/sysdev/mpic.c | 8 +++++++-
> >>> 1 file changed, 7 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> >>> index 1be54fa..bdcb858 100644
> >>> --- a/arch/powerpc/sysdev/mpic.c
> >>> +++ b/arch/powerpc/sysdev/mpic.c
> >>> @@ -1088,8 +1088,14 @@ static int mpic_host_map(struct irq_domain *h, unsigned int virq,
> >>> * is done here.
> >>> */
> >>> if (!mpic_is_ipi(mpic, hw) && (mpic->flags & MPIC_NO_RESET)) {
> >>> + int cpu;
> >>> +
> >>> + preempt_disable();
> >>> + cpu = mpic_processor_id(mpic);
> >>> + preempt_enable();
> >>> +
> >>
> >> Any reason you didn't stick this inside of mpic_processor_id() ?
> >
> > Because the debug check might be valid for other callers and we don't
> > want to defeat it. In this caller it's used only as a heuristic and
> > thus it doesn't matter if we re-enable preemption before using the
> > result.
>
> Gotcha, I think you should reword the commit message. Reading it makes
> me think that preemption should be disabled for all mpic_processor_id()
> calls.
It should be disabled for all mpic_processor_id() calls -- but some
calls will need preemption to be disabled for longer than just the call
to mpic_processor_id().
I did mention in the commit message why mpic_host_map() is unusual.
BTW, I wonder why we don't use mpic_set_affinity (and thus
irq_choose_cpu), both here and in the non-MPIC_NO_RESET case. Though I
usually notice IRQs being round robinned -- I guess userspace is writing
to the affinity in proc? Or is something elsewhere in the kernel
calling set_affinity at some point?
Another thing I just noticed while looking at IRQ_DESTINATION-related
code, in mpic_teardown_this_cpu(), what stops it from removing the only
CPU that an interrupt is targeted at?
-Scott
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox