* Re: [PATCH] powerpc: inline ppc64_runlatch_off
From: Benjamin Herrenschmidt @ 2010-08-06 6:25 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev
In-Reply-To: <20100806055640.GS29316@kryten>
On Fri, 2010-08-06 at 15:56 +1000, Anton Blanchard wrote:
> Unfortunately we still need to prevent continual writes to it with a per thread
> flag because on some CPUs a write to the SPR in low priority mode will stall
> another SMT thread. So we could get rid of the cpu feature comparison but
> we would still need the thread bit check (or perhaps replace it with a per cpu
> variable).
remind me why we need to do that runlatch thing on these CPUs at all ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: inline ppc64_runlatch_off
From: Anton Blanchard @ 2010-08-06 6:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1281075949.2168.31.camel@pasglop>
Hi,
> remind me why we need to do that runlatch thing on these CPUs at all ?
The PMU uses it so events can be constructed that count only non idle cycles.
I think the power management hardware on POWER6 and POWER7 also use the
runlatch state to determine how busy a CPU is.
Anton
^ permalink raw reply
* Re: [PATCH][RFC] preempt_count corruption across H_CEDE call with CONFIG_PREEMPT on pseries
From: Darren Hart @ 2010-08-06 7:13 UTC (permalink / raw)
To: svaidy
Cc: Stephen Rothwell, Gautham R Shenoy, Steven Rostedt, linuxppc-dev,
Will Schmidt, Paul Mackerras, Thomas Gleixner
In-Reply-To: <20100806050936.GI3282@dirshya.in.ibm.com>
On 08/05/2010 10:09 PM, Vaidyanathan Srinivasan wrote:
> * Darren Hart<dvhltc@us.ibm.com> [2010-08-05 19:19:00]:
>
>> On 07/22/2010 10:09 PM, Benjamin Herrenschmidt wrote:
>>> On Thu, 2010-07-22 at 21:44 -0700, Darren Hart wrote:
>>>
>>>> suggestion I updated the instrumentation to display the
>>>> local_save_flags and irqs_disabled_flags:
>>>
>>>> Jul 22 23:36:58 igoort1 kernel: local flags: 0, irqs disabled: 1
>>>> Jul 22 23:36:58 igoort1 kernel: before H_CEDE current->stack: c00000010e9e3ce0, pcnt: 1
>>>> Jul 22 23:36:58 igoort1 kernel: after H_CEDE current->stack: c00000010e9e3ce0, pcnt: 1
>>>>
>>>> I'm not sure if I'm reading that right, but I believe interrupts are
>>>> intended to be disabled here. If accomplished via the
>>>> spin_lock_irqsave() this would behave differently on RT. However, this
>>>> path disables the interrupts handled by xics, all but the IPIs anyway.
>>>> On RT I disabled the decrementer as well.
>>>>
>>>> Is it possible for RT to be receiving other interrupts here?
>>>
>>> Also you may want to call hard_irq_disable() to -really- disable
>>> interrupts ... since we do lazy-disable on powerpc
>>>
>>
>> A quick update and request for direction wrt the cede hcall, interrupt handling, and the stack pointer.
>>
>> I've added patches one at a time, eliminating bugs with preempt_rt
>> (tip/rt/head). With my current patchset I have no crashes with a single run of
>> random_online.sh (stress testing to hit the hang will sees is my todo for
>> tomorrow).
>>
>> Current patchset includes:
>> patches/0001-wms-fix01.patch # P7 lazy flushing thing
>>
>> # next four are sent to / queued for mainline
>> patches/powerpc-increase-pseries_cpu_die-delay.patch
>> patches/powerpc-enable-preemption-before-cpu_die.patch
>> patches/powerpc-silence-__cpu_up-under-normal-operation.patch
>> patches/powerpc-silence-xics_migrate_irqs_away-during-cpu-offline.patch
>>
>> # this one needs to be cleaned up and sent to mainline
>> patches/powerpc-wait-for-cpu-to-go-inactive.patch
>>
>> patches/powerpc-disable-decrementer-on-offline.patch
>> patches/powerpc-cpu_die-preempt-hack.patch # reset preempt_count to 0 after cede
>> patches/powerpc-cede-processor-inst.patch # instrumentation
>> patches/powerpc-hard_irq_disable.patch # hard_irq_disable before cede
>> patches/powerpc-pad-thread_info.patch
>>
>> I didn't include all the patches as the relevant bits are included below in
>> code form.
>>
>> With the instrumentation, it's clear the change to preempt_count() is targeted
>> (since I added padding before and after preempt_count in the thread_info
>> struct) and preempt_count is still changed. It is also clear that it isn't just
>> a stray decrement since I set preempt_count() to 4 prior to calling cede and it
>> still is 0xffffffff after the hcall. Also note that the stack pointer doesn't
>> change across the cede call and neither does any other part of the thread_info
>> structure.
>>
>> Adding hard_irq_disable() did seem to affect things somewhat. Rather than a
>> serialized list of before/after thread_info prints around cede, I see
>> several befores then several afters. But the preempt_count is still modified.
>>
>> The relevant code looks like this (from pseries_mach_cpu_die())
>>
>> hard_irq_disable(); /* this doesn't fix things... but
>> does change behavior a bit */
>> preempt_count() = 0x4;
>> asm("mr %0,1" : "=r" (sp)); /* stack pointer is in R1 */
>> printk("before cede: sp=%lx pcnt=%x\n", sp, preempt_count());
>> print_thread_info();
>> extended_cede_processor(cede_latency_hint);
>> asm("mr %0,1" : "=r" (sp));
>> printk("after cede: sp=%lx pcnt=%x\n", sp, preempt_count());
>> print_thread_info();
>> preempt_count() = 0;
>>
>>
>> With these patches applied, the output across cede looks like:
>>
>> before cede: sp=c000000000b57150 pcnt=4
>> *** current->thread_info ***
>> ti->task: c000000000aa1410
>> ti->exec_domain: c000000000a59958
>> ti->cpu: 0
>> ti->stomp_on_me: 57005 /* 0xDEAD - forgot to print in hex */
>> ti->preempt_count: 4
>> ti->stomp_on_me_too: 48879 /* 0xBEEF - forgot to print in hex */
>> ti->local_flags: 0
>> *** end thread_info ***
>> after cede: sp=c000000000b57150 pcnt=ffffffff
>> *** current->thread_info ***
>> ti->task: c000000000aa1410
>> ti->exec_domain: c000000000a59958
>> ti->cpu: 0
>
> Is this print sufficient to prove that we did not jump CPU?
Probably not, but the following should be sufficient. Note that the
dump occurs on "CPU: 6" which matches the CPU noted in the ti->cpu
before and after the cede call.
*** current->thread_info ***
ti->task: c00000008e7b2240
ti->exec_domain: c000000000a59958
ti->cpu: 6
ti->stomp_on_me: 57005
ti->preempt_count: 4
ti->stomp_on_me_too: 48879
ti->local_flags: 0
*** end thread_info ***
------------[ cut here ]------------
Badness at kernel/sched.c:3698
NIP: c0000000006987e4 LR: c0000000006987c8 CTR: c00000000005c668
REGS: c00000010e713800 TRAP: 0700 Not tainted (2.6.33-rt-dvhrt05-02358-g61223dd-dirty)
MSR: 8000000000021032 <ME,CE,IR,DR> CR: 24000082 XER: 20000000
TASK = c00000008e7b2240[0] 'swapper' THREAD: c00000010e710000 CPU: 6
GPR00: 0000000000000000 c00000010e713a80 c000000000b54f88 0000000000000001
GPR04: c00000010e713d08 ffffffffffffffff 00000000000000e0 800000000d049138
GPR08: 0000000000000000 c000000000ca5420 0000000000000001 c000000000bc22e8
GPR12: 0000000000000002 c000000000ba5080 0000000000000000 000000000f394b6c
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: c000000000ba50c0 0000000000000004 0000000000000002 0000000000000000
GPR24: 0000000000000004 c00000010e713cd0 c0000000009f1ecc c00000000088aaff
GPR28: 0000000000000000 0000000000000001 c000000000ad7610 c00000010e713a80
NIP [c0000000006987e4] .add_preempt_count+0x6c/0xe0
LR [c0000000006987c8] .add_preempt_count+0x50/0xe0
Call Trace:
[c00000010e713a80] [c00000010e713b30] 0xc00000010e713b30 (unreliable)
[c00000010e713b10] [c0000000000824b4] .vprintk+0xac/0x480
[c00000010e713c40] [c00000000069bcbc] .printk+0x48/0x5c
[c00000010e713cd0] [c00000000005c190] .pseries_mach_cpu_die+0x1c4/0x39c
[c00000010e713db0] [c00000000001e7e0] .cpu_die+0x4c/0x68
[c00000010e713e30] [c000000000017de0] .cpu_idle+0x1f8/0x220
[c00000010e713ed0] [c0000000006a17c4] .start_secondary+0x394/0x3d4
[c00000010e713f90] [c000000000008264] .start_secondary_prolog+0x10/0x14
Instruction dump:
78290464 80090018 2f800000 40fc002c 4bd089c1 60000000 2fa30000 419e006c
e93e87e0 80090000 2f800000 409e005c <0fe00000> 48000054 e97e8398 78290464
after cede: sp=c00000010e713cd0 pcnt=ffffffff
*** current->thread_info ***
ti->task: c00000008e7b2240
ti->exec_domain: c000000000a59958
ti->cpu: 6
ti->stomp_on_me: 57005
ti->preempt_count: fffffffe
ti->stomp_on_me_too: 48879
ti->local_flags: 0
*** end thread_info ***
> We agree that decrementer can possibly expire and we could have gone
> to the handler and come back just like we would do in an idle loop.
I disable the decrementer in the stop_cpu path... that may not be
sufficient for the pseries_mach_cpu_die() path, I'll have to experiment.
However, even if it did, it shouldn't be just changing the value,
especially not to something illegal.
> This will not happen always, but I could see a window of time during
> which this may happen. But that should not change the preempt_count
> unconditionally to -1 with the same stack pointer.
>
>> ti->stomp_on_me: 57005
>> ti->preempt_count: ffffffff
>> ti->stomp_on_me_too: 48879
>> ti->local_flags: 0
>
> Is there a method to identify whether we had executed any of the
> interrupt handler while in this code?
I'd like to know as well. If anyone knows, please share. Otherwise
I'll be trying to sort that out tomorrow.
>
>> *** end thread_info ***
>>
>> Are there any additional thoughts on what might be causing preempt_count to change?
>> I was thinking that cede might somehow force it to 0 (or perhaps one of the
>> preempt_count explicit value setters in irq.c) and then decrement it - but that dec
>> should trigger an error in the dec_preempt_count() as I have CONFIG_DEBUG_PREEMPT=y.
>
> Decrementer is only the suspect, we have not yet proved that the dec
> handler is being executed. Can somebody be using our stack? The
> pointer is same.. but do we still own it? I cannot think of how
> somebody else could be using this cpu's stack... but just a thought to
> explain this anomaly.
>
> --Vaidy
Thanks for the thoughts,
--
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
^ permalink raw reply
* Re: [PATCH] powerpc: inline ppc64_runlatch_off
From: Olof Johansson @ 2010-08-06 8:02 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev
In-Reply-To: <20100806045315.GR29316@kryten>
On Fri, Aug 06, 2010 at 02:53:15PM +1000, Anton Blanchard wrote:
>
> I'm sick of seeing ppc64_runlatch_off in our profiles, so inline the
> heavily used part of it into the callers. To avoid a mess of circular includes
> I didn't add it as an inline function.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
> ---
>
> Index: powerpc.git/arch/powerpc/include/asm/reg.h
> ===================================================================
> --- powerpc.git.orig/arch/powerpc/include/asm/reg.h 2010-08-04 19:55:38.910793475 +1000
> +++ powerpc.git/arch/powerpc/include/asm/reg.h 2010-08-04 20:20:19.490751850 +1000
> @@ -951,7 +951,14 @@
> #ifdef CONFIG_PPC64
>
> extern void ppc64_runlatch_on(void);
> -extern void ppc64_runlatch_off(void);
> +extern void __ppc64_runlatch_off(void);
> +
> +#define ppc64_runlatch_off() \
> + do { \
> + if (cpu_has_feature(CPU_FTR_CTRL) && \
> + test_thread_flag(TIF_RUNLATCH)) \
> + __ppc64_runlatch_off(); \
> + } while (0);
No semicolon here.
-Olof
^ permalink raw reply
* How to disable eTSEC2 in MPC837xerdb
From: Ravi Gupta @ 2010-08-06 12:14 UTC (permalink / raw)
To: linuxppc-dev, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1697 bytes --]
Hi,
I am trying to disable eTSEC2 in mpc8377erdb freescale board. I had removed
the entry corresponding to enet2 from the dts file and updated the firmware
to use the new dtb file. Now when I boot the board I can still see the eth1
entry in the ifconfig -a output. Is there something that I am missing.
Please advice.
Old dts: contains 2 entries enet0 and enet1*
* enet0: ethernet@24000 {
cell-index = <0>;
device_type = "network";
model = "eTSEC";
compatible = "gianfar";
reg = <0x24000 0x1000>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <32 0x8 33 0x8 34 0x8>;
phy-connection-type = "mii";
interrupt-parent = <&ipic>;
phy-handle = <&phy2>;
sleep = <0xb00 0xc0000000>;
fsl,magic-packet;
};
enet1: ethernet@25000 {
cell-index = <1>;
device_type = "network";
model = "eTSEC";
compatible = "gianfar";
reg = <0x25000 0x1000>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <35 0x8 36 0x8 37 0x8>;
phy-connection-type = "mii";
interrupt-parent = <&ipic>;
fixed-link = <1 1 1000 0 0>;
sleep = <0xb00 0x30000000>;
fsl,magic-packet;
};
New dts: single enet entry
*
* enet0: ethernet@24000 {
cell-index = <0>;
device_type = "network";
model = "eTSEC";
compatible = "gianfar";
reg = <0x24000 0x1000>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <32 0x8 33 0x8 34 0x8>;
phy-connection-type = "mii";
interrupt-parent = <&ipic>;
phy-handle = <&phy2>;
sleep = <0xb00 0xc0000000>;
fsl,magic-packet;
};
Thanks in advance
Ravi Gupta
[-- Attachment #2: Type: text/html, Size: 2178 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: inline ppc64_runlatch_off
From: Anton Blanchard @ 2010-08-06 13:28 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20100806080227.GA17423@lixom.net>
Hi Olof,
> No semicolon here.
Nice catch!
Anton
I'm sick of seeing ppc64_runlatch_off in our profiles, so inline it
into the callers. To avoid a mess of circular includes I didn't add
it as an inline function.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/include/asm/reg.h
===================================================================
--- powerpc.git.orig/arch/powerpc/include/asm/reg.h 2010-08-04 19:55:38.910793475 +1000
+++ powerpc.git/arch/powerpc/include/asm/reg.h 2010-08-04 20:20:19.490751850 +1000
@@ -951,7 +951,14 @@
#ifdef CONFIG_PPC64
extern void ppc64_runlatch_on(void);
-extern void ppc64_runlatch_off(void);
+extern void __ppc64_runlatch_off(void);
+
+#define ppc64_runlatch_off() \
+ do { \
+ if (cpu_has_feature(CPU_FTR_CTRL) && \
+ test_thread_flag(TIF_RUNLATCH)) \
+ __ppc64_runlatch_off(); \
+ } while (0)
extern unsigned long scom970_read(unsigned int address);
extern void scom970_write(unsigned int address, unsigned long value);
Index: powerpc.git/arch/powerpc/kernel/process.c
===================================================================
--- powerpc.git.orig/arch/powerpc/kernel/process.c 2010-08-04 19:55:38.890747120 +1000
+++ powerpc.git/arch/powerpc/kernel/process.c 2010-08-04 20:15:27.573241044 +1000
@@ -1198,19 +1198,17 @@ void ppc64_runlatch_on(void)
}
}
-void ppc64_runlatch_off(void)
+void __ppc64_runlatch_off(void)
{
unsigned long ctrl;
- if (cpu_has_feature(CPU_FTR_CTRL) && test_thread_flag(TIF_RUNLATCH)) {
- HMT_medium();
+ HMT_medium();
- clear_thread_flag(TIF_RUNLATCH);
+ clear_thread_flag(TIF_RUNLATCH);
- ctrl = mfspr(SPRN_CTRLF);
- ctrl &= ~CTRL_RUNLATCH;
- mtspr(SPRN_CTRLT, ctrl);
- }
+ ctrl = mfspr(SPRN_CTRLF);
+ ctrl &= ~CTRL_RUNLATCH;
+ mtspr(SPRN_CTRLT, ctrl);
}
#endif
^ permalink raw reply
* Re: [PATCH 00/27] KVM PPC PV framework v3
From: Kumar Gala @ 2010-08-06 16:28 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <1280407688-9815-1-git-send-email-agraf@suse.de>
On Jul 29, 2010, at 7:47 AM, Alexander Graf wrote:
> [without]
>=20
> debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello > =
/dev/null; done
>=20
> real 0m14.659s
> user 0m8.967s
> sys 0m5.688s
>=20
> [with]
>=20
> debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello > =
/dev/null; done
>=20
> real 0m7.557s
> user 0m4.121s
> sys 0m3.426s
Do you have #'s for w/o HV to compare to.
- k=
^ permalink raw reply
* [PATCH] powerpc: fix i8042 module build error
From: Grant Likely @ 2010-08-06 18:42 UTC (permalink / raw)
To: martyn.welch, benh, linuxppc-dev, linux-kernel, sfr
of_i8042_{kbd,aux}_irq needs to be exported
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Stephen and Ben, this fixes up the build error in linux-next. If you prefer,
I can stuff this patch into my next-powerpc branch. Ben, I've got other
commits in that branch that I'll be sending to you early next week anyway.
arch/powerpc/kernel/setup-common.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 15ade0d..9d4882a 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -96,7 +96,9 @@ struct screen_info screen_info = {
/* Variables required to store legacy IO irq routing */
int of_i8042_kbd_irq;
+EXPORT_SYMBOL_GPL(of_i8042_kbd_irq);
int of_i8042_aux_irq;
+EXPORT_SYMBOL_GPL(of_i8042_aux_irq);
#ifdef __DO_IRQ_CANON
/* XXX should go elsewhere eventually */
^ permalink raw reply related
* Re: [PATCH 0/2 v3] mpc5200 ac97 gpio reset
From: Grant Likely @ 2010-08-06 18:44 UTC (permalink / raw)
To: Eric Millbrandt; +Cc: Mark Brown, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <0A40042D85E7C84DB443060EC44B3FD325420B9123@dekaexchange07.deka.local>
On Thu, Aug 5, 2010 at 6:59 AM, Eric Millbrandt
<emillbrandt@dekaresearch.com> wrote:
>> -----Original Message-----
>> From: linuxppc-dev-bounces+emillbrandt=3Ddekaresearch.com@lists.ozlabs.o=
rg
>> [mailto:linuxppc-dev-
>> bounces+emillbrandt=3Ddekaresearch.com@lists.ozlabs.org] On Behalf Of Ma=
rk
>> Brown
>> Sent: Tuesday, August 03, 2010 01:52
>> To: Grant Likely
>> Cc: linuxppc-dev@lists.ozlabs.org; Eric Millbrandt
>> Subject: Re: [PATCH 0/2 v3] mpc5200 ac97 gpio reset
>>
>> On Sat, Jul 31, 2010 at 10:42:15PM -0600, Grant Likely wrote:
>> > On Sun, Jun 27, 2010 at 4:01 PM, Mark Brown
>>
>> > > I'm a little concerned with a collision with multi codec here. It'd
>> > > be handy if you could keep it separate in case it needs merging
>> > > into both trees (or we could merge via ASoC only).
>>
>> > Hmmm. =A0Yeah, probably better to take it via your tree then. =A0I've
>> > currently got patch 1 in linux-next, but I'll drop it before asking
>> > benh to pull. =A0Go ahead and add my acked-by.
>>
>> Looks like multi-component is slightly too late for .36 and I don't have
>> the original patch any more since it looked like you were going to be
>> carrying it... =A0could you restore the patch to your tree please?
>
> <ping> Grant, are you going to pick up this series for .36?
Yes, working on it... :-)
g.
^ permalink raw reply
* Re: Relocating bootwrapper causes kernel panic
From: Benjamin Herrenschmidt @ 2010-08-06 22:49 UTC (permalink / raw)
To: Scott Wood; +Cc: ppcdev
In-Reply-To: <20100805134654.70f8f787@schlenkerla.am.freescale.net>
\
> Probably. You won't have any page tables yet, much less an entry for
> the device tree.
>
> > >> I think the cause is clear now. But how to fix it? Two questions:
> > >> 2. If the DTLB miss exception handler is not the right guy to load a
> > >> proper TLB entry, how can I set one entry based on the link_address
> > >> and the address of the flat dt blob?
> > >
> > > Given how early in the boot process it is, it's probably going to need
> > > to be handled specially.
> >
> > What APIs can I use to set up DTLBs?
>
> I don't think there is one that works on 8xx. You'll could hack up
> initial_mmu, or else write some C code to insert an 8xx TLB entry.
Yup, I think he just ends up getting out of the initial mapping which is
smallish on 8xx, no ? Might be worth sticking in one more entry during
boot...
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: fix i8042 module build error
From: Stephen Rothwell @ 2010-08-07 0:01 UTC (permalink / raw)
To: Grant Likely; +Cc: martyn.welch, linuxppc-dev, linux-kernel
In-Reply-To: <20100806183839.32149.6238.stgit@angua>
[-- Attachment #1: Type: text/plain, Size: 656 bytes --]
Hi Grant,
On Fri, 06 Aug 2010 12:42:12 -0600 Grant Likely <grant.likely@secretlab.ca> wrote:
>
> of_i8042_{kbd,aux}_irq needs to be exported
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
>
> Stephen and Ben, this fixes up the build error in linux-next. If you prefer,
> I can stuff this patch into my next-powerpc branch. Ben, I've got other
> commits in that branch that I'll be sending to you early next week anyway.
This failure also exists in Linus' tree, so the earlier this goes to
Linus the better.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: fix i8042 module build error
From: Grant Likely @ 2010-08-07 2:54 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: martyn.welch, linuxppc-dev, linux-kernel
In-Reply-To: <20100807100123.886d3a1e.sfr@canb.auug.org.au>
On Fri, Aug 6, 2010 at 6:01 PM, Stephen Rothwell <sfr@canb.auug.org.au> wro=
te:
> Hi Grant,
>
> On Fri, 06 Aug 2010 12:42:12 -0600 Grant Likely <grant.likely@secretlab.c=
a> wrote:
>>
>> of_i8042_{kbd,aux}_irq needs to be exported
>>
>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>> ---
>>
>> Stephen and Ben, this fixes up the build error in linux-next. =A0If you =
prefer,
>> I can stuff this patch into my next-powerpc branch. =A0Ben, I've got oth=
er
>> commits in that branch that I'll be sending to you early next week anywa=
y.
>
> This failure also exists in Linus' tree, so the earlier this goes to
> Linus the better.
Okay then. Ben, I'll send out my pull request out right away so
you've got it if you want to use it.
Cheers,
g.
> --
> Cheers,
> Stephen Rothwell =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sfr@canb.auug.org=
.au
> http://www.canb.auug.org.au/~sfr/
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [git pull] powerpc allmodconfig build fix and missed 5200 audio drivers (Was: [PATCH] powerpc: fix i8042 module build error)
From: Grant Likely @ 2010-08-07 3:55 UTC (permalink / raw)
To: Stephen Rothwell, Benjamin Herrenschmidt
Cc: martyn.welch, linuxppc-dev, Eric Millbrandt
Hi Ben, Here's the promised pull request:
Let me know if this is okay, or if you would like to respin it.
The 2 mpc5200 patches are in here (and not in my previous request)
because of a breakdown in coordination between me and the ASoC folks.
Turns out the (potentially) conflicting patches weren't ready for
2.6.36, so Mark asked me to pick them back up[1]. It also has the
powerpc allmodconfig build failure fix.
[1]http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg45616.html
Cheers,
g.
The following changes since commit 17879857821adad4e180c5d6457c3b8bbf1d0c0c=
:
Linus Torvalds (1):
Merge branch 'irq-core-for-linus' of
git://git.kernel.org/.../tip/linux-2.6-tip
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6 next
Eric Millbrandt (2):
powerpc/5200: add mpc5200_psc_ac97_gpio_reset
sound/soc: mpc5200_psc_ac97: Use gpio pins for cold reset
Grant Likely (1):
powerpc: fix i8042 module build error
arch/powerpc/include/asm/mpc52xx.h | 1 +
arch/powerpc/include/asm/mpc52xx_psc.h | 1 +
arch/powerpc/kernel/setup-common.c | 2 +
arch/powerpc/platforms/52xx/mpc52xx_common.c | 106 ++++++++++++++++++++++=
++++
sound/soc/fsl/mpc5200_psc_ac97.c | 22 +++++-
5 files changed, 128 insertions(+), 4 deletions(-)
On Fri, Aug 6, 2010 at 8:54 PM, Grant Likely <grant.likely@secretlab.ca> wr=
ote:
> On Fri, Aug 6, 2010 at 6:01 PM, Stephen Rothwell <sfr@canb.auug.org.au> w=
rote:
>> Hi Grant,
>>
>> On Fri, 06 Aug 2010 12:42:12 -0600 Grant Likely <grant.likely@secretlab.=
ca> wrote:
>>>
>>> of_i8042_{kbd,aux}_irq needs to be exported
>>>
>>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>>> ---
>>>
>>> Stephen and Ben, this fixes up the build error in linux-next. =A0If you=
prefer,
>>> I can stuff this patch into my next-powerpc branch. =A0Ben, I've got ot=
her
>>> commits in that branch that I'll be sending to you early next week anyw=
ay.
>>
>> This failure also exists in Linus' tree, so the earlier this goes to
>> Linus the better.
>
> Okay then. =A0Ben, I'll send out my pull request out right away so
> you've got it if you want to use it.
>
> Cheers,
> g.
>> --
>> Cheers,
>> Stephen Rothwell =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sfr@canb.auug.or=
g.au
>> http://www.canb.auug.org.au/~sfr/
>>
>
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] powerpc/mpc8xxx_gpio.c: extend the driver to support mpc512x gpios
From: Anatolij Gustschin @ 2010-08-07 13:28 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Anatolij Gustschin, Wolfgang Denk, Detlev Zundel
In-Reply-To: <87iq4r5y4q.fsf@macbook.be.48ers.dk>
Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
arch/powerpc/platforms/Kconfig | 7 ++--
arch/powerpc/sysdev/mpc8xxx_gpio.c | 54 +++++++++++++++++++++++++++++++++++-
2 files changed, 57 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index d1663db..471115a 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -304,13 +304,14 @@ config OF_RTC
source "arch/powerpc/sysdev/bestcomm/Kconfig"
config MPC8xxx_GPIO
- bool "MPC8xxx GPIO support"
- depends on PPC_MPC831x || PPC_MPC834x || PPC_MPC837x || FSL_SOC_BOOKE || PPC_86xx
+ bool "MPC512x/MPC8xxx GPIO support"
+ depends on PPC_MPC512x || PPC_MPC831x || PPC_MPC834x || PPC_MPC837x || \
+ FSL_SOC_BOOKE || PPC_86xx
select GENERIC_GPIO
select ARCH_REQUIRE_GPIOLIB
help
Say Y here if you're going to use hardware that connects to the
- MPC831x/834x/837x/8572/8610 GPIOs.
+ MPC512x/831x/834x/837x/8572/8610 GPIOs.
config SIMPLE_GPIO
bool "Support for simple, memory-mapped GPIO controllers"
diff --git a/arch/powerpc/sysdev/mpc8xxx_gpio.c b/arch/powerpc/sysdev/mpc8xxx_gpio.c
index 2b69084..f5b4959 100644
--- a/arch/powerpc/sysdev/mpc8xxx_gpio.c
+++ b/arch/powerpc/sysdev/mpc8xxx_gpio.c
@@ -1,5 +1,5 @@
/*
- * GPIOs on MPC8349/8572/8610 and compatible
+ * GPIOs on MPC512x/8349/8572/8610 and compatible
*
* Copyright (C) 2008 Peter Korsgaard <jacmet@sunsite.dk>
*
@@ -26,6 +26,7 @@
#define GPIO_IER 0x0c
#define GPIO_IMR 0x10
#define GPIO_ICR 0x14
+#define GPIO_ICR2 0x18
struct mpc8xxx_gpio_chip {
struct of_mm_gpio_chip mm_gc;
@@ -215,6 +216,51 @@ static int mpc8xxx_irq_set_type(unsigned int virq, unsigned int flow_type)
return 0;
}
+static int mpc512x_irq_set_type(unsigned int virq, unsigned int flow_type)
+{
+ struct mpc8xxx_gpio_chip *mpc8xxx_gc = get_irq_chip_data(virq);
+ struct of_mm_gpio_chip *mm = &mpc8xxx_gc->mm_gc;
+ unsigned long gpio = virq_to_hw(virq);
+ void __iomem *reg;
+ unsigned int shift;
+ unsigned long flags;
+
+ if (gpio < 16) {
+ reg = mm->regs + GPIO_ICR;
+ shift = (15 - gpio) * 2;
+ } else {
+ reg = mm->regs + GPIO_ICR2;
+ shift = (15 - (gpio % 16)) * 2;
+ }
+
+ switch (flow_type) {
+ case IRQ_TYPE_EDGE_FALLING:
+ case IRQ_TYPE_LEVEL_LOW:
+ spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
+ clrsetbits_be32(reg, 3 << shift, 2 << shift);
+ spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
+ break;
+
+ case IRQ_TYPE_EDGE_RISING:
+ case IRQ_TYPE_LEVEL_HIGH:
+ spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
+ clrsetbits_be32(reg, 3 << shift, 1 << shift);
+ spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
+ break;
+
+ case IRQ_TYPE_EDGE_BOTH:
+ spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
+ clrbits32(reg, 3 << shift);
+ spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
+ break;
+
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static struct irq_chip mpc8xxx_irq_chip = {
.name = "mpc8xxx-gpio",
.unmask = mpc8xxx_irq_unmask,
@@ -226,6 +272,9 @@ static struct irq_chip mpc8xxx_irq_chip = {
static int mpc8xxx_gpio_irq_map(struct irq_host *h, unsigned int virq,
irq_hw_number_t hw)
{
+ if (of_device_is_compatible(h->of_node, "fsl,mpc5121-gpio"))
+ mpc8xxx_irq_chip.set_type = mpc512x_irq_set_type;
+
set_irq_chip_data(virq, h->host_data);
set_irq_chip_and_handler(virq, &mpc8xxx_irq_chip, handle_level_irq);
set_irq_type(virq, IRQ_TYPE_NONE);
@@ -330,6 +379,9 @@ static int __init mpc8xxx_add_gpiochips(void)
for_each_compatible_node(np, NULL, "fsl,mpc8610-gpio")
mpc8xxx_add_controller(np);
+ for_each_compatible_node(np, NULL, "fsl,mpc5121-gpio")
+ mpc8xxx_add_controller(np);
+
return 0;
}
arch_initcall(mpc8xxx_add_gpiochips);
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] powerpc/mpc8xxx_gpio.c: extend the driver to support mpc512x gpios
From: Grant Likely @ 2010-08-07 15:12 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev, Wolfgang Denk, Detlev Zundel
In-Reply-To: <1281187711-10215-1-git-send-email-agust@denx.de>
Hi Anatolij,
Looks pretty good, but some comments below...
On Sat, Aug 7, 2010 at 7:28 AM, Anatolij Gustschin <agust@denx.de> wrote:
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
You haven't written a patch description. Give some details about how
the 512x gpio controller is different from the 8xxx one.
> ---
> =A0arch/powerpc/platforms/Kconfig =A0 =A0 | =A0 =A07 ++--
> =A0arch/powerpc/sysdev/mpc8xxx_gpio.c | =A0 54 ++++++++++++++++++++++++++=
+++++++++-
> =A02 files changed, 57 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kcon=
fig
> index d1663db..471115a 100644
> --- a/arch/powerpc/platforms/Kconfig
> +++ b/arch/powerpc/platforms/Kconfig
> @@ -304,13 +304,14 @@ config OF_RTC
> =A0source "arch/powerpc/sysdev/bestcomm/Kconfig"
>
> =A0config MPC8xxx_GPIO
> - =A0 =A0 =A0 bool "MPC8xxx GPIO support"
> - =A0 =A0 =A0 depends on PPC_MPC831x || PPC_MPC834x || PPC_MPC837x || FSL=
_SOC_BOOKE || PPC_86xx
> + =A0 =A0 =A0 bool "MPC512x/MPC8xxx GPIO support"
> + =A0 =A0 =A0 depends on PPC_MPC512x || PPC_MPC831x || PPC_MPC834x || PPC=
_MPC837x || \
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0FSL_SOC_BOOKE || PPC_86xx
> =A0 =A0 =A0 =A0select GENERIC_GPIO
> =A0 =A0 =A0 =A0select ARCH_REQUIRE_GPIOLIB
> =A0 =A0 =A0 =A0help
> =A0 =A0 =A0 =A0 =A0Say Y here if you're going to use hardware that connec=
ts to the
> - =A0 =A0 =A0 =A0 MPC831x/834x/837x/8572/8610 GPIOs.
> + =A0 =A0 =A0 =A0 MPC512x/831x/834x/837x/8572/8610 GPIOs.
>
> =A0config SIMPLE_GPIO
> =A0 =A0 =A0 =A0bool "Support for simple, memory-mapped GPIO controllers"
> diff --git a/arch/powerpc/sysdev/mpc8xxx_gpio.c b/arch/powerpc/sysdev/mpc=
8xxx_gpio.c
> index 2b69084..f5b4959 100644
> --- a/arch/powerpc/sysdev/mpc8xxx_gpio.c
> +++ b/arch/powerpc/sysdev/mpc8xxx_gpio.c
> @@ -1,5 +1,5 @@
> =A0/*
> - * GPIOs on MPC8349/8572/8610 and compatible
> + * GPIOs on MPC512x/8349/8572/8610 and compatible
> =A0*
> =A0* Copyright (C) 2008 Peter Korsgaard <jacmet@sunsite.dk>
> =A0*
> @@ -26,6 +26,7 @@
> =A0#define GPIO_IER =A0 =A0 =A0 =A0 =A0 =A0 =A0 0x0c
> =A0#define GPIO_IMR =A0 =A0 =A0 =A0 =A0 =A0 =A0 0x10
> =A0#define GPIO_ICR =A0 =A0 =A0 =A0 =A0 =A0 =A0 0x14
> +#define GPIO_ICR2 =A0 =A0 =A0 =A0 =A0 =A0 =A00x18
>
> =A0struct mpc8xxx_gpio_chip {
> =A0 =A0 =A0 =A0struct of_mm_gpio_chip mm_gc;
> @@ -215,6 +216,51 @@ static int mpc8xxx_irq_set_type(unsigned int virq, u=
nsigned int flow_type)
> =A0 =A0 =A0 =A0return 0;
> =A0}
>
> +static int mpc512x_irq_set_type(unsigned int virq, unsigned int flow_typ=
e)
> +{
> + =A0 =A0 =A0 struct mpc8xxx_gpio_chip *mpc8xxx_gc =3D get_irq_chip_data(=
virq);
> + =A0 =A0 =A0 struct of_mm_gpio_chip *mm =3D &mpc8xxx_gc->mm_gc;
> + =A0 =A0 =A0 unsigned long gpio =3D virq_to_hw(virq);
> + =A0 =A0 =A0 void __iomem *reg;
> + =A0 =A0 =A0 unsigned int shift;
> + =A0 =A0 =A0 unsigned long flags;
> +
> + =A0 =A0 =A0 if (gpio < 16) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 reg =3D mm->regs + GPIO_ICR;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 shift =3D (15 - gpio) * 2;
> + =A0 =A0 =A0 } else {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 reg =3D mm->regs + GPIO_ICR2;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 shift =3D (15 - (gpio % 16)) * 2;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 switch (flow_type) {
> + =A0 =A0 =A0 case IRQ_TYPE_EDGE_FALLING:
> + =A0 =A0 =A0 case IRQ_TYPE_LEVEL_LOW:
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 spin_lock_irqsave(&mpc8xxx_gc->lock, flags)=
;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 clrsetbits_be32(reg, 3 << shift, 2 << shift=
);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 spin_unlock_irqrestore(&mpc8xxx_gc->lock, f=
lags);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
> +
> + =A0 =A0 =A0 case IRQ_TYPE_EDGE_RISING:
> + =A0 =A0 =A0 case IRQ_TYPE_LEVEL_HIGH:
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 spin_lock_irqsave(&mpc8xxx_gc->lock, flags)=
;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 clrsetbits_be32(reg, 3 << shift, 1 << shift=
);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 spin_unlock_irqrestore(&mpc8xxx_gc->lock, f=
lags);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
> +
> + =A0 =A0 =A0 case IRQ_TYPE_EDGE_BOTH:
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 spin_lock_irqsave(&mpc8xxx_gc->lock, flags)=
;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 clrbits32(reg, 3 << shift);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 spin_unlock_irqrestore(&mpc8xxx_gc->lock, f=
lags);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
> +
> + =A0 =A0 =A0 default:
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 return 0;
> +}
> +
> =A0static struct irq_chip mpc8xxx_irq_chip =3D {
> =A0 =A0 =A0 =A0.name =A0 =A0 =A0 =A0 =A0 =3D "mpc8xxx-gpio",
> =A0 =A0 =A0 =A0.unmask =A0 =A0 =A0 =A0 =3D mpc8xxx_irq_unmask,
> @@ -226,6 +272,9 @@ static struct irq_chip mpc8xxx_irq_chip =3D {
> =A0static int mpc8xxx_gpio_irq_map(struct irq_host *h, unsigned int virq,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0irq_hw_num=
ber_t hw)
> =A0{
> + =A0 =A0 =A0 if (of_device_is_compatible(h->of_node, "fsl,mpc5121-gpio")=
)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mpc8xxx_irq_chip.set_type =3D mpc512x_irq_s=
et_type;
> +
You can put the set type hook into the of_match_table data which you
will need for of_find_matching_node() (see below).
> =A0 =A0 =A0 =A0set_irq_chip_data(virq, h->host_data);
> =A0 =A0 =A0 =A0set_irq_chip_and_handler(virq, &mpc8xxx_irq_chip, handle_l=
evel_irq);
> =A0 =A0 =A0 =A0set_irq_type(virq, IRQ_TYPE_NONE);
> @@ -330,6 +379,9 @@ static int __init mpc8xxx_add_gpiochips(void)
> =A0 =A0 =A0 =A0for_each_compatible_node(np, NULL, "fsl,mpc8610-gpio")
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mpc8xxx_add_controller(np);
>
> + =A0 =A0 =A0 for_each_compatible_node(np, NULL, "fsl,mpc5121-gpio")
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mpc8xxx_add_controller(np);
> +
This list is getting too long. Refactor this function to use
for_each_matching_node(). Also doing it this way is dangerous because
if say a 5121 gpio node claims compatibility with a 8610 gpio node,
then the gpio controller will get registered twice.
> =A0 =A0 =A0 =A0return 0;
> =A0}
> =A0arch_initcall(mpc8xxx_add_gpiochips);
> --
> 1.7.0.4
>
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* PLX9030 port
From: vivek @ 2010-08-07 16:06 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 952 bytes --]
Hello all
I am new to the mail list
I am trying to port the driver for PLX9030 PCI host chip based add-on card from x86 to PPC7410 arch
the following function function returns NULL
pci_get_device(0x10b5, 0x9030, NULL)
vendor ID given for PLX is 0x10b5
device ID is 0x9030
These values worked and the module found the device in x86 platform,
But the same code is complied and inserted on PPC7410 platform, the modules failed to detect the device
Is there any Endianness conversion to be performed before passing the values to pci_get_device() in hex format ?
I am using linux 2.6.24 kernel and
while make-ing the module ,ko file for PPC7410 using cross_complier gcc_74xx-
there was a WARNING message "struct_module undefined "
But it is possible to insert the module in the kernel running on PPC7410, which then printk 's the message when pci_get_device() returns NULL
can anyone help?
thnaks --vivek
[-- Attachment #2: Type: text/html, Size: 1486 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/mpc8xxx_gpio.c: extend the driver to support mpc512x gpios
From: Anatolij Gustschin @ 2010-08-07 16:39 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Wolfgang Denk, Detlev Zundel
In-Reply-To: <AANLkTimopiF3MZfaAXOO1rJVTptP0HFWSTtmSviAcfT3@mail.gmail.com>
Hi Grant,
On Sat, 7 Aug 2010 09:12:50 -0600
Grant Likely <grant.likely@secretlab.ca> wrote:
> Hi Anatolij,
>=20
> Looks pretty good, but some comments below...
>=20
> On Sat, Aug 7, 2010 at 7:28 AM, Anatolij Gustschin <agust@denx.de> wrote:
> > Signed-off-by: Anatolij Gustschin <agust@denx.de>
>=20
> You haven't written a patch description. Give some details about how
> the 512x gpio controller is different from the 8xxx one.
Ok, will fix.
...
> > @@ -226,6 +272,9 @@ static struct irq_chip mpc8xxx_irq_chip =3D {
> > =A0static int mpc8xxx_gpio_irq_map(struct irq_host *h, unsigned int vir=
q,
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0irq_hw_n=
umber_t hw)
> > =A0{
> > + =A0 =A0 =A0 if (of_device_is_compatible(h->of_node, "fsl,mpc5121-gpio=
"))
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mpc8xxx_irq_chip.set_type =3D mpc512x_irq=
_set_type;
> > +
>=20
> You can put the set type hook into the of_match_table data which you
> will need for of_find_matching_node() (see below).
How can I get this match table data reference in mpc8xxx_gpio_irq_map() ?
Is it okay to set data field of struct device_node to the set type
hook? I could do it in mpc8xxx_add_gpiochips() but I'm not sure whether
the data field will be used for other purposes somewhere else.
...
> > @@ -330,6 +379,9 @@ static int __init mpc8xxx_add_gpiochips(void)
> > =A0 =A0 =A0 =A0for_each_compatible_node(np, NULL, "fsl,mpc8610-gpio")
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mpc8xxx_add_controller(np);
> >
> > + =A0 =A0 =A0 for_each_compatible_node(np, NULL, "fsl,mpc5121-gpio")
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mpc8xxx_add_controller(np);
> > +
>=20
> This list is getting too long. Refactor this function to use
> for_each_matching_node(). Also doing it this way is dangerous because
> if say a 5121 gpio node claims compatibility with a 8610 gpio node,
> then the gpio controller will get registered twice.
Fixed.
Thanks,
Anatolij
^ permalink raw reply
* Re: [PATCH] powerpc/mpc8xxx_gpio.c: extend the driver to support mpc512x gpios
From: Grant Likely @ 2010-08-07 16:58 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev, Wolfgang Denk, Detlev Zundel
In-Reply-To: <20100807183932.4ee10757@wker>
On Sat, Aug 7, 2010 at 10:39 AM, Anatolij Gustschin <agust@denx.de> wrote:
> Grant Likely <grant.likely@secretlab.ca> wrote:
>> > @@ -226,6 +272,9 @@ static struct irq_chip mpc8xxx_irq_chip =3D {
>> > =A0static int mpc8xxx_gpio_irq_map(struct irq_host *h, unsigned int vi=
rq,
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0irq_hw_=
number_t hw)
>> > =A0{
>> > + =A0 =A0 =A0 if (of_device_is_compatible(h->of_node, "fsl,mpc5121-gpi=
o"))
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mpc8xxx_irq_chip.set_type =3D mpc512x_ir=
q_set_type;
>> > +
>>
>> You can put the set type hook into the of_match_table data which you
>> will need for of_find_matching_node() (see below).
>
> How can I get this match table data reference in mpc8xxx_gpio_irq_map() ?
of_match_node() will return the matching entry in the table.
> Is it okay to set data field of struct device_node to the set type
> hook? I could do it in mpc8xxx_add_gpiochips() but I'm not sure whether
> the data field will be used for other purposes somewhere else.
You are safe to use the .data field.
g.
^ permalink raw reply
* Re: make 3.82 fails on powerpc defconfig update [was: Linux 2.6.35]
From: Paul Smith @ 2010-08-07 17:56 UTC (permalink / raw)
To: Thomas Backlund; +Cc: linuxppc-dev, Linux Kernel Mailing List, bug-make
In-Reply-To: <4C5686FF.9010803@mandriva.org>
On Mon, 2010-08-02 at 11:51 +0300, Thomas Backlund wrote:
> BOOT_TARGETS = zImage zImage.initrd uImage zImage% dtbImage%
> treeImage.% cuImage.% simpleImage.%
>
> Now, I dont know if this is "intended breakage" by the make update, or
> if the Makefile needs to be updated....
The change is intentional. Note, though, that this syntax was always
dodgy, even in previous versions of GNU make.
If you wrote it exactly as you did, where all the explicit targets come
first and all the implicit targets come second, then it seems to have
been interpreted correctly.
However, if you did it any other way (for example, put some explicit
targets after the first implicit target) then make would silently throw
away all the targets starting with the first implicit target.
Since the syntax used here wasn't ever described in the documentation,
rather than reworking it as a new feature I decided to follow the docs
and disallow it, and be verbose about the error.
--
-------------------------------------------------------------------------------
Paul D. Smith <psmith@gnu.org> Find some GNU make tips at:
http://www.gnu.org http://make.mad-scientist.net
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
^ permalink raw reply
* [PATCH v2] powerpc/mpc8xxx_gpio.c: extend the driver to support mpc512x gpios
From: Anatolij Gustschin @ 2010-08-07 19:03 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Anatolij Gustschin, Wolfgang Denk, Detlev Zundel
In-Reply-To: <1281187711-10215-1-git-send-email-agust@denx.de>
The GPIO controller of MPC512x is slightly different from
8xxx GPIO controllers. The register interface is the same
except the external interrupt control register. The MPC512x
GPIO controller differentiates between four interrupt event
types and therefore provides two interrupt control registers,
GPICR1 and GPICR2. GPIO[0:15] interrupt event types are
configured in GPICR1 register, GPIO[16:31] - in GPICR2 register.
This patch adds MPC512x speciffic set_type() callback and
updates config file and comments. Additionally the gpio chip
registration function is changed to use for_each_matching_node()
preventing multiple registration if a node claimes compatibility
with another gpio controller type.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
v2:
- add patch description
- use match table data to set irq set_type hook as
recommended
- refactor to use for_each_matching_node() in
mpc8xxx_add_gpiochips() as suggested by Grant
arch/powerpc/platforms/Kconfig | 7 ++-
arch/powerpc/sysdev/mpc8xxx_gpio.c | 72 ++++++++++++++++++++++++++++++++----
2 files changed, 68 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index d1663db..471115a 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -304,13 +304,14 @@ config OF_RTC
source "arch/powerpc/sysdev/bestcomm/Kconfig"
config MPC8xxx_GPIO
- bool "MPC8xxx GPIO support"
- depends on PPC_MPC831x || PPC_MPC834x || PPC_MPC837x || FSL_SOC_BOOKE || PPC_86xx
+ bool "MPC512x/MPC8xxx GPIO support"
+ depends on PPC_MPC512x || PPC_MPC831x || PPC_MPC834x || PPC_MPC837x || \
+ FSL_SOC_BOOKE || PPC_86xx
select GENERIC_GPIO
select ARCH_REQUIRE_GPIOLIB
help
Say Y here if you're going to use hardware that connects to the
- MPC831x/834x/837x/8572/8610 GPIOs.
+ MPC512x/831x/834x/837x/8572/8610 GPIOs.
config SIMPLE_GPIO
bool "Support for simple, memory-mapped GPIO controllers"
diff --git a/arch/powerpc/sysdev/mpc8xxx_gpio.c b/arch/powerpc/sysdev/mpc8xxx_gpio.c
index 2b69084..87ad655 100644
--- a/arch/powerpc/sysdev/mpc8xxx_gpio.c
+++ b/arch/powerpc/sysdev/mpc8xxx_gpio.c
@@ -1,5 +1,5 @@
/*
- * GPIOs on MPC8349/8572/8610 and compatible
+ * GPIOs on MPC512x/8349/8572/8610 and compatible
*
* Copyright (C) 2008 Peter Korsgaard <jacmet@sunsite.dk>
*
@@ -26,6 +26,7 @@
#define GPIO_IER 0x0c
#define GPIO_IMR 0x10
#define GPIO_ICR 0x14
+#define GPIO_ICR2 0x18
struct mpc8xxx_gpio_chip {
struct of_mm_gpio_chip mm_gc;
@@ -215,6 +216,51 @@ static int mpc8xxx_irq_set_type(unsigned int virq, unsigned int flow_type)
return 0;
}
+static int mpc512x_irq_set_type(unsigned int virq, unsigned int flow_type)
+{
+ struct mpc8xxx_gpio_chip *mpc8xxx_gc = get_irq_chip_data(virq);
+ struct of_mm_gpio_chip *mm = &mpc8xxx_gc->mm_gc;
+ unsigned long gpio = virq_to_hw(virq);
+ void __iomem *reg;
+ unsigned int shift;
+ unsigned long flags;
+
+ if (gpio < 16) {
+ reg = mm->regs + GPIO_ICR;
+ shift = (15 - gpio) * 2;
+ } else {
+ reg = mm->regs + GPIO_ICR2;
+ shift = (15 - (gpio % 16)) * 2;
+ }
+
+ switch (flow_type) {
+ case IRQ_TYPE_EDGE_FALLING:
+ case IRQ_TYPE_LEVEL_LOW:
+ spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
+ clrsetbits_be32(reg, 3 << shift, 2 << shift);
+ spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
+ break;
+
+ case IRQ_TYPE_EDGE_RISING:
+ case IRQ_TYPE_LEVEL_HIGH:
+ spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
+ clrsetbits_be32(reg, 3 << shift, 1 << shift);
+ spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
+ break;
+
+ case IRQ_TYPE_EDGE_BOTH:
+ spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
+ clrbits32(reg, 3 << shift);
+ spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
+ break;
+
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static struct irq_chip mpc8xxx_irq_chip = {
.name = "mpc8xxx-gpio",
.unmask = mpc8xxx_irq_unmask,
@@ -226,6 +272,9 @@ static struct irq_chip mpc8xxx_irq_chip = {
static int mpc8xxx_gpio_irq_map(struct irq_host *h, unsigned int virq,
irq_hw_number_t hw)
{
+ if (h->of_node && h->of_node->data)
+ mpc8xxx_irq_chip.set_type = h->of_node->data;
+
set_irq_chip_data(virq, h->host_data);
set_irq_chip_and_handler(virq, &mpc8xxx_irq_chip, handle_level_irq);
set_irq_type(virq, IRQ_TYPE_NONE);
@@ -317,18 +366,25 @@ err:
return;
}
+static struct of_device_id mpc8xxx_gpio_ids[] __initdata = {
+ { .compatible = "fsl,mpc8349-gpio", },
+ { .compatible = "fsl,mpc8572-gpio", },
+ { .compatible = "fsl,mpc8610-gpio", },
+ { .compatible = "fsl,mpc5121-gpio", .data = mpc512x_irq_set_type, },
+ {}
+};
+
static int __init mpc8xxx_add_gpiochips(void)
{
+ const struct of_device_id *id;
struct device_node *np;
- for_each_compatible_node(np, NULL, "fsl,mpc8349-gpio")
- mpc8xxx_add_controller(np);
-
- for_each_compatible_node(np, NULL, "fsl,mpc8572-gpio")
- mpc8xxx_add_controller(np);
-
- for_each_compatible_node(np, NULL, "fsl,mpc8610-gpio")
+ for_each_matching_node(np, mpc8xxx_gpio_ids) {
+ id = of_match_node(mpc8xxx_gpio_ids, np);
+ if (id)
+ np->data = id->data;
mpc8xxx_add_controller(np);
+ }
return 0;
}
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH v2] powerpc/mpc8xxx_gpio.c: extend the driver to support mpc512x gpios
From: Grant Likely @ 2010-08-08 0:40 UTC (permalink / raw)
To: Anatolij Gustschin, linuxppc-dev; +Cc: Wolfgang Denk, Detlev Zundel
In-Reply-To: <1281207816-31807-1-git-send-email-agust@denx.de>
"Anatolij Gustschin" <agust@denx.de> wrote:
>The GPIO controller of MPC512x is slightly different from
>8xxx GPIO controllers. The register interface is the same
>except the external interrupt control register. The MPC512x
>GPIO controller differentiates between four interrupt event
>types and therefore provides two interrupt control registers,
>GPICR1 and GPICR2. GPIO[0:15] interrupt event types are
>configured in GPICR1 register, GPIO[16:31] - in GPICR2 register.
>
>This patch adds MPC512x speciffic set_type() callback and
>updates config file and comments. Additionally the gpio chip
>registration function is changed to use for_each_matching_node()
>preventing multiple registration if a node claimes compatibility
>with another gpio controller type.
>
>Signed-off-by: Anatolij Gustschin <agust@denx.de>
>---
>v2:
> - add patch description
> - use match table data to set irq set_type hook as
> recommended
> - refactor to use for_each_matching_node() in
> mpc8xxx_add_gpiochips() as suggested by Grant
>
> arch/powerpc/platforms/Kconfig | 7 ++-
> arch/powerpc/sysdev/mpc8xxx_gpio.c | 72 ++++++++++++++++++++++++++++++++----
> 2 files changed, 68 insertions(+), 11 deletions(-)
>
>diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
>index d1663db..471115a 100644
>--- a/arch/powerpc/platforms/Kconfig
>+++ b/arch/powerpc/platforms/Kconfig
>@@ -304,13 +304,14 @@ config OF_RTC
> source "arch/powerpc/sysdev/bestcomm/Kconfig"
>
> config MPC8xxx_GPIO
>- bool "MPC8xxx GPIO support"
>- depends on PPC_MPC831x || PPC_MPC834x || PPC_MPC837x || FSL_SOC_BOOKE || PPC_86xx
>+ bool "MPC512x/MPC8xxx GPIO support"
>+ depends on PPC_MPC512x || PPC_MPC831x || PPC_MPC834x || PPC_MPC837x || \
>+ FSL_SOC_BOOKE || PPC_86xx
> select GENERIC_GPIO
> select ARCH_REQUIRE_GPIOLIB
> help
> Say Y here if you're going to use hardware that connects to the
>- MPC831x/834x/837x/8572/8610 GPIOs.
>+ MPC512x/831x/834x/837x/8572/8610 GPIOs.
>
> config SIMPLE_GPIO
> bool "Support for simple, memory-mapped GPIO controllers"
>diff --git a/arch/powerpc/sysdev/mpc8xxx_gpio.c b/arch/powerpc/sysdev/mpc8xxx_gpio.c
>index 2b69084..87ad655 100644
>--- a/arch/powerpc/sysdev/mpc8xxx_gpio.c
>+++ b/arch/powerpc/sysdev/mpc8xxx_gpio.c
>@@ -1,5 +1,5 @@
> /*
>- * GPIOs on MPC8349/8572/8610 and compatible
>+ * GPIOs on MPC512x/8349/8572/8610 and compatible
> *
> * Copyright (C) 2008 Peter Korsgaard <jacmet@sunsite.dk>
> *
>@@ -26,6 +26,7 @@
> #define GPIO_IER 0x0c
> #define GPIO_IMR 0x10
> #define GPIO_ICR 0x14
>+#define GPIO_ICR2 0x18
>
> struct mpc8xxx_gpio_chip {
> struct of_mm_gpio_chip mm_gc;
>@@ -215,6 +216,51 @@ static int mpc8xxx_irq_set_type(unsigned int virq, unsigned int flow_type)
> return 0;
> }
>
>+static int mpc512x_irq_set_type(unsigned int virq, unsigned int flow_type)
>+{
>+ struct mpc8xxx_gpio_chip *mpc8xxx_gc = get_irq_chip_data(virq);
>+ struct of_mm_gpio_chip *mm = &mpc8xxx_gc->mm_gc;
>+ unsigned long gpio = virq_to_hw(virq);
>+ void __iomem *reg;
>+ unsigned int shift;
>+ unsigned long flags;
>+
>+ if (gpio < 16) {
>+ reg = mm->regs + GPIO_ICR;
>+ shift = (15 - gpio) * 2;
>+ } else {
>+ reg = mm->regs + GPIO_ICR2;
>+ shift = (15 - (gpio % 16)) * 2;
>+ }
>+
>+ switch (flow_type) {
>+ case IRQ_TYPE_EDGE_FALLING:
>+ case IRQ_TYPE_LEVEL_LOW:
>+ spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
>+ clrsetbits_be32(reg, 3 << shift, 2 << shift);
>+ spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
>+ break;
>+
>+ case IRQ_TYPE_EDGE_RISING:
>+ case IRQ_TYPE_LEVEL_HIGH:
>+ spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
>+ clrsetbits_be32(reg, 3 << shift, 1 << shift);
>+ spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
>+ break;
>+
>+ case IRQ_TYPE_EDGE_BOTH:
>+ spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
>+ clrbits32(reg, 3 << shift);
>+ spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
>+ break;
>+
>+ default:
>+ return -EINVAL;
>+ }
>+
>+ return 0;
>+}
>+
> static struct irq_chip mpc8xxx_irq_chip = {
> .name = "mpc8xxx-gpio",
> .unmask = mpc8xxx_irq_unmask,
>@@ -226,6 +272,9 @@ static struct irq_chip mpc8xxx_irq_chip = {
> static int mpc8xxx_gpio_irq_map(struct irq_host *h, unsigned int virq,
> irq_hw_number_t hw)
> {
>+ if (h->of_node && h->of_node->data)
>+ mpc8xxx_irq_chip.set_type = h->of_node->data;
>+
> set_irq_chip_data(virq, h->host_data);
> set_irq_chip_and_handler(virq, &mpc8xxx_irq_chip, handle_level_irq);
> set_irq_type(virq, IRQ_TYPE_NONE);
>@@ -317,18 +366,25 @@ err:
> return;
> }
>
>+static struct of_device_id mpc8xxx_gpio_ids[] __initdata = {
>+ { .compatible = "fsl,mpc8349-gpio", },
>+ { .compatible = "fsl,mpc8572-gpio", },
>+ { .compatible = "fsl,mpc8610-gpio", },
>+ { .compatible = "fsl,mpc5121-gpio", .data = mpc512x_irq_set_type, },
>+ {}
>+};
>+
> static int __init mpc8xxx_add_gpiochips(void)
> {
>+ const struct of_device_id *id;
> struct device_node *np;
>
>- for_each_compatible_node(np, NULL, "fsl,mpc8349-gpio")
>- mpc8xxx_add_controller(np);
>-
>- for_each_compatible_node(np, NULL, "fsl,mpc8572-gpio")
>- mpc8xxx_add_controller(np);
>-
>- for_each_compatible_node(np, NULL, "fsl,mpc8610-gpio")
>+ for_each_matching_node(np, mpc8xxx_gpio_ids) {
>+ id = of_match_node(mpc8xxx_gpio_ids, np);
>+ if (id)
>+ np->data = id->data;
> mpc8xxx_add_controller(np);
>+ }
Sorry, I miss led you. id->data is fine, but don't use np->data.
Call of_match_node() inside mpc8xxx_add_controller() instead, or
change the function signature to pass it in explicitly...
Actually, there is absolutely no reason to keep mpc8xxx_add_gpiochip()
as a separate function with the simplification of
mpc8xxx_add_gpiochips(). I'd simplify the whole thing by merging the
two functions together.
g.
^ permalink raw reply
* Re: [PATCH v2] powerpc/mpc8xxx_gpio.c: extend the driver to support mpc512x gpios
From: Anton Vorontsov @ 2010-08-08 7:40 UTC (permalink / raw)
To: Grant Likely
Cc: linuxppc-dev, Anatolij Gustschin, Wolfgang Denk, Detlev Zundel
In-Reply-To: <AANLkTim7uCTYLTwj0Gqen3dAi9iNO7te8NCs6wWj7nSi@mail.gmail.com>
On Sat, Aug 07, 2010 at 06:40:22PM -0600, Grant Likely wrote:
[...]
> > static int __init mpc8xxx_add_gpiochips(void)
> > {
> >+ const struct of_device_id *id;
> > struct device_node *np;
> >
> >- for_each_compatible_node(np, NULL, "fsl,mpc8349-gpio")
> >- mpc8xxx_add_controller(np);
> >-
> >- for_each_compatible_node(np, NULL, "fsl,mpc8572-gpio")
> >- mpc8xxx_add_controller(np);
> >-
> >- for_each_compatible_node(np, NULL, "fsl,mpc8610-gpio")
> >+ for_each_matching_node(np, mpc8xxx_gpio_ids) {
> >+ id = of_match_node(mpc8xxx_gpio_ids, np);
> >+ if (id)
> >+ np->data = id->data;
> > mpc8xxx_add_controller(np);
> >+ }
[...]
> Actually, there is absolutely no reason to keep mpc8xxx_add_gpiochip()
> as a separate function with the simplification of
> mpc8xxx_add_gpiochips(). I'd simplify the whole thing by merging the
> two functions together.
You mean mpc8xxx_add_controller()? Putting 65-line function
on a second indentation level, inside the for loop... sounds
like a bad idea.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH] powerpc/85xx: Add P1021 PCI IDs and quirks
From: Anton Vorontsov @ 2010-08-08 14:03 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
This is needed for proper PCI-E support on P1021 SoCs.
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
---
arch/powerpc/sysdev/fsl_pci.c | 2 ++
include/linux/pci_ids.h | 2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 209384b..4ae9332 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -399,6 +399,8 @@ DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_P1013E, quirk_fsl_pcie_header);
DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_P1013, quirk_fsl_pcie_header);
DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_P1020E, quirk_fsl_pcie_header);
DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_P1020, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_P1021E, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_P1021, quirk_fsl_pcie_header);
DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_P1022E, quirk_fsl_pcie_header);
DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_P1022, quirk_fsl_pcie_header);
DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_P2010E, quirk_fsl_pcie_header);
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index c81eec4..fc987b4 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2300,6 +2300,8 @@
#define PCI_DEVICE_ID_P2010 0x0079
#define PCI_DEVICE_ID_P1020E 0x0100
#define PCI_DEVICE_ID_P1020 0x0101
+#define PCI_DEVICE_ID_P1021E 0x0102
+#define PCI_DEVICE_ID_P1021 0x0103
#define PCI_DEVICE_ID_P1011E 0x0108
#define PCI_DEVICE_ID_P1011 0x0109
#define PCI_DEVICE_ID_P1022E 0x0110
--
1.7.0.5
^ permalink raw reply related
* [PATCH] mmc_spi: Fix unterminated of_match_table
From: Anton Vorontsov @ 2010-08-08 14:14 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-kernel
commit 2ffe8c5f323c3b9749bf7bc2375d909d20bdbb15 ("of: refactor
of_modalias_node() and remove explicit match table"), introduced
an unterminated of_match_table, which may cause kernel to oops.
This patch fixes the issue by adding an empty device ID.
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
---
drivers/mmc/host/mmc_spi.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
index 7b0f3ef..1145ea0 100644
--- a/drivers/mmc/host/mmc_spi.c
+++ b/drivers/mmc/host/mmc_spi.c
@@ -1536,6 +1536,7 @@ static int __devexit mmc_spi_remove(struct spi_device *spi)
#if defined(CONFIG_OF)
static struct of_device_id mmc_spi_of_match_table[] __devinitdata = {
{ .compatible = "mmc-spi-slot", },
+ {},
};
#endif
--
1.7.0.5
^ permalink raw reply related
* Re: [PATCH] mmc_spi: Fix unterminated of_match_table
From: Grant Likely @ 2010-08-08 15:02 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, Andrew Morton, linux-kernel
In-Reply-To: <20100808141422.GA9670@oksana.dev.rtsoft.ru>
On Sun, Aug 8, 2010 at 8:14 AM, Anton Vorontsov <avorontsov@mvista.com> wro=
te:
> commit 2ffe8c5f323c3b9749bf7bc2375d909d20bdbb15 ("of: refactor
> of_modalias_node() and remove explicit match table"), introduced
> an unterminated of_match_table, which may cause kernel to oops.
>
> This patch fixes the issue by adding an empty device ID.
>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
Thanks Anton. Merged into my next-devicetree branch.
g.
> ---
> =A0drivers/mmc/host/mmc_spi.c | =A0 =A01 +
> =A01 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
> index 7b0f3ef..1145ea0 100644
> --- a/drivers/mmc/host/mmc_spi.c
> +++ b/drivers/mmc/host/mmc_spi.c
> @@ -1536,6 +1536,7 @@ static int __devexit mmc_spi_remove(struct spi_devi=
ce *spi)
> =A0#if defined(CONFIG_OF)
> =A0static struct of_device_id mmc_spi_of_match_table[] __devinitdata =3D =
{
> =A0 =A0 =A0 =A0{ .compatible =3D "mmc-spi-slot", },
> + =A0 =A0 =A0 {},
> =A0};
> =A0#endif
>
> --
> 1.7.0.5
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ 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