* Re: [V2 PATCH 06/10] of/drivers: Always use struct device.of_node to get node pointer
From: Grant Likely @ 2010-03-18 17:07 UTC (permalink / raw)
To: Sean MacLennan
Cc: linux-kernel, michal.simek, microblaze-uclinux, sparclinux,
linuxppc-dev, davem
In-Reply-To: <20100318125939.2b39d7f2@lappy.seanm.ca>
On Thu, Mar 18, 2010 at 10:59 AM, Sean MacLennan
<smaclennan@pikatech.com> wrote:
> On Thu, 18 Mar 2010 09:22:39 -0600
> Grant Likely <grant.likely@secretlab.ca> wrote:
>
>> The following structure elements duplicate the information in
>> 'struct device.of_node' and so are being eliminated. =A0This patches
>> makes all readers of the following elements use device.of_node
>> instead.
>
> The NDFC driver also needs a patch... or at least the version from your
> last of_patch set does. I am included the patch I needed to get it to
> compile.
Thanks Sean, I've added this patch to my series. s-o-b line please?
g.
^ permalink raw reply
* Re: [V2 PATCH 06/10] of/drivers: Always use struct device.of_node to get node pointer
From: Sean MacLennan @ 2010-03-18 17:10 UTC (permalink / raw)
To: Grant Likely
Cc: linux-kernel, michal.simek, microblaze-uclinux, sparclinux,
linuxppc-dev, davem
In-Reply-To: <fa686aa41003181007k9202cd6n44d2d3997ef626a1@mail.gmail.com>
On Thu, 18 Mar 2010 11:07:35 -0600
Grant Likely <grant.likely@secretlab.ca> wrote:
> On Thu, Mar 18, 2010 at 10:59 AM, Sean MacLennan
> <smaclennan@pikatech.com> wrote:
> > On Thu, 18 Mar 2010 09:22:39 -0600
> > Grant Likely <grant.likely@secretlab.ca> wrote:
> >
> >> The following structure elements duplicate the information in
> >> 'struct device.of_node' and so are being eliminated. =A0This patches
> >> makes all readers of the following elements use device.of_node
> >> instead.
> >
> > The NDFC driver also needs a patch... or at least the version from
> > your last of_patch set does. I am included the patch I needed to
> > get it to compile.
>=20
> Thanks Sean, I've added this patch to my series. s-o-b line please?
>=20
> g.
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
index 19d94a2..5a232ec 100644
--- a/drivers/mtd/nand/ndfc.c
+++ b/drivers/mtd/nand/ndfc.c
@@ -238,14 +238,14 @@ static int __devinit ndfc_probe(struct of_device *ofd=
ev,
dev_set_drvdata(&ofdev->dev, ndfc);
=20
/* Read the reg property to get the chip select */
- reg =3D of_get_property(ofdev->node, "reg", &len);
+ reg =3D of_get_property(ofdev->dev.of_node, "reg", &len);
if (reg =3D=3D NULL || len !=3D 12) {
dev_err(&ofdev->dev, "unable read reg property (%d)\n", len);
return -ENOENT;
}
ndfc->chip_select =3D reg[0];
=20
- ndfc->ndfcbase =3D of_iomap(ofdev->node, 0);
+ ndfc->ndfcbase =3D of_iomap(ofdev->dev.of_node, 0);
if (!ndfc->ndfcbase) {
dev_err(&ofdev->dev, "failed to get memory\n");
return -EIO;
@@ -254,20 +254,20 @@ static int __devinit ndfc_probe(struct of_device *ofd=
ev,
ccr =3D NDFC_CCR_BS(ndfc->chip_select);
=20
/* It is ok if ccr does not exist - just default to 0 */
- reg =3D of_get_property(ofdev->node, "ccr", NULL);
+ reg =3D of_get_property(ofdev->dev.of_node, "ccr", NULL);
if (reg)
ccr |=3D *reg;
=20
out_be32(ndfc->ndfcbase + NDFC_CCR, ccr);
=20
/* Set the bank settings if given */
- reg =3D of_get_property(ofdev->node, "bank-settings", NULL);
+ reg =3D of_get_property(ofdev->dev.of_node, "bank-settings", NULL);
if (reg) {
int offset =3D NDFC_BCFG0 + (ndfc->chip_select << 2);
out_be32(ndfc->ndfcbase + offset, *reg);
}
=20
- err =3D ndfc_chip_init(ndfc, ofdev->node);
+ err =3D ndfc_chip_init(ndfc, ofdev->dev.of_node);
if (err) {
iounmap(ndfc->ndfcbase);
return err;
^ permalink raw reply related
* Re: [V2 PATCH 06/10] of/drivers: Always use struct device.of_node to get node pointer
From: Sean MacLennan @ 2010-03-18 17:12 UTC (permalink / raw)
To: Grant Likely
Cc: linux-kernel, michal.simek, microblaze-uclinux, sparclinux,
linuxppc-dev, davem
In-Reply-To: <20100318152238.21082.10985.stgit@angua>
On Thu, 18 Mar 2010 09:22:39 -0600
Grant Likely <grant.likely@secretlab.ca> wrote:
> The following structure elements duplicate the information in
> 'struct device.of_node' and so are being eliminated. This patches
> makes all readers of the following elements use device.of_node
> instead.
Acked-by: Sean MacLennan <smaclennan@pikatech.com>
^ permalink raw reply
* Does ppc cpio have limit in size?
From: wilbur.chan @ 2010-03-18 17:39 UTC (permalink / raw)
To: linuxppc-dev
Recently I 'm using cpio filesystem (kernel and filesystem compressed
as a whole) on ppc8270 .
However I found that the bigger the size of uImage is , the easier
kernel failed when booting.
Everytime it failed when calling "populate_rootfs" when booting, so I
guess maybe the size of uImage effect booting procedure.
Anyone know how to boot a large cpio uImage ? Thank you!
regards,
wilbur
^ permalink raw reply
* Re: IRQ's missing with MPC5200 GPT as an interrupt controller
From: Grant Likely @ 2010-03-18 18:02 UTC (permalink / raw)
To: Henk Stegeman; +Cc: linuxppc-dev
In-Reply-To: <ae4f76fd1003080620o5598778cv221f05bf331768c8@mail.gmail.com>
Hi Henk,
On Mon, Mar 8, 2010 at 8:20 AM, Henk Stegeman <henk.stegeman@gmail.com> wro=
te:
> I'm trying to make use of the GPT as interrupt controller.
> My driver is getting most, but not all of the interrupts, besides that
> I'm getting a whole bunch of spurious IRQs, so I'm trying to figure
> out what's wrong.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gpt6: timer@660 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible =3D "fsl,mpc520=
0b-gpt","fsl,mpc5200-gpt";
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0x660 0x10>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interrupts =3D <1 15 0>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interrupt-controller;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#interrupt-cells =3D <1>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
>
> My device has the interrupt-parent property which links it to the
> above interrupt controller.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0spi@f00 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#address-cells =3D <1>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#size-cells =3D <0>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible =3D "fsl,mpc520=
0b-spi","fsl,mpc5200-spi";
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0xf00 0x20>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interrupts =3D <2 13 0 2 1=
4 0>;
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0io-controller@0 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible=
=3D "microkey,smc4000io";
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0linux,moda=
lias =3D "of_smc4000io";
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0spi-max-fr=
equency =3D <800000>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0spi-cpha;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0=
>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0word-delay=
-us =3D <30>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interrupt-=
parent =3D <&gpt6>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interrupts=
=3D <2>; // And make it edge falling
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
>
> There are two things I find suspicious:
> - First of all my interrupt is listed as virq# 16, shouldn't it be
> virq# 0x50 ? (16 is te L2 value virq# 0x50 of mpc52xx_irqhost_map)
The GPT irq registered as a different IRQ controller, so it will be
assigned an entirely different number within the virq range.
> - Secondly in mpc52xx_gpt.c =A0mpc52xx_gpt_irq_mask() and
> mpc52xx_gpt_irq_unmask() resp. clear and set the IrqEn bit of the GPT,
> which is described in the MPC5200B_UM as "enables interrupt generation
> to the CPU for all modes". The word 'generation' makes me suspicious,
> because it could mean that while irqEn is cleared an edge on the GPT's
> input does not even request an IRQ immediately after the bit is
> cleared. =A0Or in other words, clearing the bit could do more that just
> masking.
Could be, the IRQ support has not gotten extensive testing. It may
require additional work.
> ~ # cat /proc/interrupts
> =A0 =A0 =A0 =A0 =A0 CPU0
> =A016: =A0 =A01338686 =A0 MPC52xx GPT =A0 =A0 =A0Edge =A0 =A0 =A0 =A0 smc=
4000io
> 129: =A0 =A0 =A083224 =A0 MPC52xx Peripherals Level =A0 =A0 =A0 =A0mpc52x=
x_psc_uart
> 130: =A0 =A0 =A0 =A0 =A01 =A0 MPC52xx Peripherals Level =A0 =A0 =A0 =A0mp=
c52xx_psc_uart
> 133: =A0 =A0 =A0 =A0 =A00 =A0 MPC52xx Peripherals Level =A0 =A0 =A0 =A0mp=
c52xx-fec_ctrl
> 134: =A0 =A0 =A0 =A0 =A00 =A0 MPC52xx Peripherals Level =A0 =A0 =A0 =A0oh=
ci_hcd:usb1
> 135: =A0 =A0 =A016127 =A0 MPC52xx Peripherals Level =A0 =A0 =A0 =A0mpc52x=
x_ata
> 141: =A0 =A0 =A0 =A0 =A00 =A0 MPC52xx Peripherals Level =A0 =A0 =A0 =A0mp=
c5200-spi-modf
> 142: =A0 =A0 =A079184 =A0 MPC52xx Peripherals Level =A0 =A0 =A0 =A0mpc520=
0-spi-spif
> 192: =A0 =A0 =A0 =A0 =A00 =A0 MPC52xx SDMA =A0 =A0 Level =A0 =A0 =A0 =A0A=
TA task
> 193: =A0 =A0 =A0 =A0 15 =A0 MPC52xx SDMA =A0 =A0 Level =A0 =A0 =A0 =A0mpc=
52xx-fec_rx
> 194: =A0 =A0 =A035615 =A0 MPC52xx SDMA =A0 =A0 Level =A0 =A0 =A0 =A0mpc52=
xx-fec_tx
> LOC: =A0 =A0 134286 =A0 Local timer interrupts
> SPU: =A0 =A0 576958 =A0 Spurious interrupts
> CNT: =A0 =A0 =A0 =A0 =A00 =A0 Performance monitoring interrupts
> MCE: =A0 =A0 =A0 =A0 =A00 =A0 Machine check exceptions
>
> ~ # dmesg |grep 660
> [ =A0 =A01.975928] irq: irq 0 on host /soc5200@f0000000/timer@660 mapped
> to virtual irq 16
>
> ~ # dmesg | grep host_map
> [ =A0 =A00.000000] mpc52xx_irqhost_map: virq=3D81, l1=3D2, l2=3D1
> [ =A0 =A00.319272] mpc52xx_irqhost_map: External IRQ1 virq=3D41, hw=3D41.=
type=3D8
> [ =A0 =A00.376117] mpc52xx_irqhost_map: virq=3D49, l1=3D1, l2=3D9
> [ =A0 =A00.417213] mpc52xx_irqhost_map: virq=3D4a, l1=3D1, l2=3D10
> [ =A0 =A00.452119] mpc52xx_irqhost_map: virq=3D4b, l1=3D1, l2=3D11
> [ =A0 =A00.487031] mpc52xx_irqhost_map: virq=3D4c, l1=3D1, l2=3D12
> [ =A0 =A00.529899] mpc52xx_irqhost_map: virq=3D4d, l1=3D1, l2=3D13
> [ =A0 =A00.564821] mpc52xx_irqhost_map: virq=3D4e, l1=3D1, l2=3D14
> [ =A0 =A00.599744] mpc52xx_irqhost_map: virq=3D4f, l1=3D1, l2=3D15
> [ =A0 =A00.634669] mpc52xx_irqhost_map: virq=3D50, l1=3D1, l2=3D16
> [ =A0 =A01.629764] mpc52xx_irqhost_map: virq=3D82, l1=3D2, l2=3D2
> [ =A0 =A01.667194] mpc52xx_irqhost_map: virq=3D84, l1=3D2, l2=3D4
> [ =A0 =A01.763299] mpc52xx_irqhost_map: virq=3D87, l1=3D2, l2=3D7
> [ =A0 =A01.790510] mpc52xx_irqhost_map: virq=3Dc0, l1=3D3, l2=3D0
> [ =A0 =A01.909341] mpc52xx_irqhost_map: virq=3D8d, l1=3D2, l2=3D13
> [ =A0 =A01.936712] mpc52xx_irqhost_map: virq=3D8e, l1=3D2, l2=3D14
> [ =A0 =A02.055579] mpc52xx_irqhost_map: virq=3Dc1, l1=3D3, l2=3D1
> [ =A0 =A02.083018] mpc52xx_irqhost_map: virq=3Dc2, l1=3D3, l2=3D2
> [ =A0 =A02.110345] mpc52xx_irqhost_map: virq=3D85, l1=3D2, l2=3D5
> [ =A0 =A02.211890] mpc52xx_irqhost_map: virq=3D86, l1=3D2, l2=3D6
This grep only shows the output from mpc52xx_intc.c. The GPT driver
has its own IRQ mapping function; mpc52xx_gpt_irq_map(), which is why
you're not seeing your IRQ map debug message.
Cheers,
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH v2] powerpc/perf_events: Implement perf_arch_fetch_caller_regs
From: Frederic Weisbecker @ 2010-03-18 19:30 UTC (permalink / raw)
To: Paul Mackerras
Cc: Peter Zijlstra, linux-kernel, linuxppc-dev, anton, Ingo Molnar
In-Reply-To: <20100318050513.GA6575@drongo>
On Thu, Mar 18, 2010 at 04:05:13PM +1100, Paul Mackerras wrote:
> This implements a powerpc version of perf_arch_fetch_caller_regs.
> It's implemented in assembly because that way we can be sure there
> isn't a stack frame for perf_arch_fetch_caller_regs. If it was in
> C, gcc might or might not create a stack frame for it, which would
> affect the number of levels we have to skip.
>
> With this, we see results from perf record -e lock:lock_acquire like
> this:
>
> # Samples: 24878
> #
> # Overhead Command Shared Object Symbol
> # ........ .............. ................. ......
> #
> 14.99% perf [kernel.kallsyms] [k] ._raw_spin_lock
> |
> --- ._raw_spin_lock
> |
> |--25.00%-- .alloc_fd
> | (nil)
> | |
> | |--50.00%-- .anon_inode_getfd
> | | .sys_perf_event_open
> | | syscall_exit
> | | syscall
> | | create_counter
> | | __cmd_record
> | | run_builtin
> | | main
> | | 0xfd2e704
> | | 0xfd2e8c0
> | | (nil)
>
> ... etc.
>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> arch/powerpc/include/asm/asm-compat.h | 2 ++
> arch/powerpc/kernel/misc.S | 28 ++++++++++++++++++++++++++++
> 2 files changed, 30 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/asm-compat.h b/arch/powerpc/include/asm/asm-compat.h
> index c1b475a..a9b91ed 100644
> --- a/arch/powerpc/include/asm/asm-compat.h
> +++ b/arch/powerpc/include/asm/asm-compat.h
> @@ -28,6 +28,7 @@
> #define PPC_LLARX(t, a, b, eh) PPC_LDARX(t, a, b, eh)
> #define PPC_STLCX stringify_in_c(stdcx.)
> #define PPC_CNTLZL stringify_in_c(cntlzd)
> +#define PPC_LR_STKOFF 16
>
> /* Move to CR, single-entry optimized version. Only available
> * on POWER4 and later.
> @@ -51,6 +52,7 @@
> #define PPC_STLCX stringify_in_c(stwcx.)
> #define PPC_CNTLZL stringify_in_c(cntlzw)
> #define PPC_MTOCRF stringify_in_c(mtcrf)
> +#define PPC_LR_STKOFF 4
>
> #endif
>
> diff --git a/arch/powerpc/kernel/misc.S b/arch/powerpc/kernel/misc.S
> index 2d29752..b485a87 100644
> --- a/arch/powerpc/kernel/misc.S
> +++ b/arch/powerpc/kernel/misc.S
> @@ -127,3 +127,31 @@ _GLOBAL(__setup_cpu_power7)
> _GLOBAL(__restore_cpu_power7)
> /* place holder */
> blr
> +
> +#ifdef CONFIG_EVENT_TRACING
> +/*
> + * Get a minimal set of registers for our caller's nth caller.
> + * r3 = regs pointer, r5 = n.
> + *
> + * We only get R1 (stack pointer), NIP (next instruction pointer)
> + * and LR (link register). These are all we can get in the
> + * general case without doing complicated stack unwinding, but
> + * fortunately they are enough to do a stack backtrace, which
> + * is all we need them for.
> + */
> +_GLOBAL(perf_arch_fetch_caller_regs)
> + mr r6,r1
> + cmpwi r5,0
> + mflr r4
> + ble 2f
> + mtctr r5
> +1: PPC_LL r6,0(r6)
> + bdnz 1b
> + PPC_LL r4,PPC_LR_STKOFF(r6)
> +2: PPC_LL r7,0(r6)
> + PPC_LL r7,PPC_LR_STKOFF(r7)
> + PPC_STL r6,GPR1-STACK_FRAME_OVERHEAD(r3)
> + PPC_STL r4,_NIP-STACK_FRAME_OVERHEAD(r3)
> + PPC_STL r7,_LINK-STACK_FRAME_OVERHEAD(r3)
> + blr
> +#endif /* CONFIG_EVENT_TRACING */
Ingo has reported me that context-switches software events
(not the trace event version) have crappy callchains.
So, while looking into it:
- PERF_COUNT_SW_CPU_MIGRATIONS provides no regs.
Heh, and it event doesn't work because of this perf_swevent_add
give up if regs are NULL.
Has PERF_COUNT_SW_CPU_MIGRATIONS ever worked?
- PERF_COUNT_SW_CONTEXT_SWITCHES uses task_pt_regs(). This
seems a very wrong thing. We don't want the regs when a user
task was interrupted or before a syscall.
That notwithstanding task_pt_regs() on kernel threads
has insane effects.
What we want for both is a hot regs snapshot.
I'm going to fix this. But it means the CONFIG_EVENT_TRACING
dependency is not true anymore. So I can't keep the exported
symbol of perf_arch_fetch_caller_regs() in trace_event_perf.c.
The ideal would be to put the EXPORT_SYMBOL in perf_event.c
but doing so in the same file a weak symbol is defined has
unpredictable effects. So I'm going to make it a macro as I
don't have the choice. I'll update ppc at the same time but I
can't guarantee it will even build :)
Thanks.
^ permalink raw reply
* Re: BUG in dma-mapping.h:218 // MESH SCSI driver not working
From: Stef Simoens @ 2010-03-18 23:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev
In-Reply-To: <7704005f23c1dfcbfdc8f1963b290d98.squirrel@www.loft5.bisse17-21.be>
[-- Attachment #1: Type: text/plain, Size: 3499 bytes --]
Hello,
Some time ago (July 24th 2009 my mailbox says) I emailed you and the
linuxppc-dev list about my problems booting from the mesh SCSI controller.
I just compiled 2.6.31 (actually, gentoo-sources-2.6.31-r10); but the
problem remains
I know that 2.6.33 is out, but as I didn't see any changes to the
mesh-driver I guess that the problem is still there ...
This is the logging I get when I boot (2.6.31):
mesh_abort(ef8501e0)
mesh: state at ef9eaa50, regs at f1010000, dma at f1014a00
ct= 1 seq=47 bs=4027 fc= 0 exc= 0 err= 0 im= 7 int= 0 sp=f0
dma stat=e0 cmdptr=2f8c2010
phase=5 msgphase=0 conn_tgt=0 data_ptr=0
dma_st=0 dma_ct=0 n_msgout=0
target 0: req=ef85901e0 goes_out=0 saved_ptr=0
mesh_abort(ef850280)
mesh: state at ef9eaa50, regs at f1010000, dma at f1014a00
ct= 1 seq=47 bs=4027 fc= 0 exc= 0 err= 0 im= 7 int= 0 sp=f0
dma stat=e0 cmdptr=2f8c2010
phase=5 msgphase=0 conn_tgt=0 data_ptr=0
dma_st=0 dma_ct=0 n_msgout=0
target 0: req=ef8501e0 goes_out=0 saved_ptr=0
mesh_host_reset
mesh_abort(ef8501e0)
mesh: state at ef9eaa50, regs at f1010000, dma at f1014a00
ct= 0 seq=6a bs=4026 fc= 5 exc= 0 err= 0 im= 7 int= 0 sp= 2
fifo data=c0
fifo data=01
fifo data=03
fifo data=01
fifo data=19
dma stat=e0 cmdptr=2f8c2010
phase=3 msgphase=1 conn_tgt=0 data_ptr=0
dma_st=0 dma_ct=0 n_msgout=6
target 0: req=ef8501e0 goes_out=0 saved_ptr=0
mesh_host_reset
...
[afterwards, it "disconnects" all the disks and then it panics as it
cannot find the root partition]
2.6.29 runs fine ... but I guess that at some point, I would like to
upgrade to the latest stable kernel.
The machine is a PowerPC9600 with a 740 upgrade card, 1GB memory, kernel
compiled with GCC 4.3.4 ...
Of course I am willing to offer you all assistance you need to help you
pin-point the problem...
Thanks for your help
Stef
Stef Simoens schreef:
> Hello Ben,
>
> Thank you for your reply.
>
>> On Fri, 2009-07-24 at 00:18 +0200, Stef Simoens wrote:
>>
>>> I tried the latest 2.6.31-rc3-git3 (without any other patch).
>>> However, I have the same behaviour as the patched 2.6.30 (so: no BUG,
>>> but the mesh_abort messages).
>>>
>> Would it be possible for you to roughly find out at what kernel version
>> it stopped working ? (Some kernels may need my patch to avoid crashing)
>>
>
> I am currently running 2.6.29-gentoo-r5 (that's somewhere at the end of
> 2.6.29, probably 2.6.29.5).
>
> I compiled 2.6.30 as soon as it came 'stable'.
> In any version of 2.6.30, I encounter the BUG (dma-mapping.h:218).
>
> I didn't react immediately, I actually guessed that the problem would have
> been reported and solved in another 2.6.30.x.
> Because it didn't, I started browsing the mailing-list (and found your
> patch).
> 2.6.30-gentoo-r3 with your patch applied doesn't give the bug,
> but gives the mesh_abort.
>
> Before asking the question, I wanted to build the latest 2.6.31-rc
> available to make sure my problem didn't get solved in the meantime.
> 2.6.31-rc3 gives the same mesh_abort.
>
> Would you like me to try all the linux-2.6.30-rc?
> Could you give me your best guess starting-point?
>
> I know that there exists something as git-disect ... but I have never used
> git (there always needs to be the first time, of course).
>
> Kind regards,
>
> Stef
>
--
Stef Simoens stef.simoens@numericable.be
+32 486 577 963 http://users.numericable.be/stef
[-- Attachment #2: Type: text/html, Size: 4652 bytes --]
^ permalink raw reply
* Re: BUG in dma-mapping.h:218 // MESH SCSI driver not working
From: Benjamin Herrenschmidt @ 2010-03-18 23:35 UTC (permalink / raw)
To: Stef Simoens; +Cc: linuxppc-dev
In-Reply-To: <4BA2B570.2010202@numericable.be>
On Fri, 2010-03-19 at 00:21 +0100, Stef Simoens wrote:
> Hello,
>
> Some time ago (July 24th 2009 my mailbox says) I emailed you and the
> linuxppc-dev list about my problems booting from the mesh SCSI
> controller.
>
> I just compiled 2.6.31 (actually, gentoo-sources-2.6.31-r10); but the
> problem remains
> I know that 2.6.33 is out, but as I didn't see any changes to the
> mesh-driver I guess that the problem is still there ...
Sadly I haven't had a chance to look. The MESH driver is a pretty
complicated thing that I didn't write and am not familiar with, so it's
going to take some work to sort out what's going on, and so far I
haven't had time to dedicate to this.
Cheers,
Ben.
> This is the logging I get when I boot (2.6.31):
>
> mesh_abort(ef8501e0)
> mesh: state at ef9eaa50, regs at f1010000, dma at f1014a00
> ct= 1 seq=47 bs=4027 fc= 0 exc= 0 err= 0 im= 7 int= 0 sp=f0
> dma stat=e0 cmdptr=2f8c2010
> phase=5 msgphase=0 conn_tgt=0 data_ptr=0
> dma_st=0 dma_ct=0 n_msgout=0
> target 0: req=ef85901e0 goes_out=0 saved_ptr=0
> mesh_abort(ef850280)
> mesh: state at ef9eaa50, regs at f1010000, dma at f1014a00
> ct= 1 seq=47 bs=4027 fc= 0 exc= 0 err= 0 im= 7 int= 0 sp=f0
> dma stat=e0 cmdptr=2f8c2010
> phase=5 msgphase=0 conn_tgt=0 data_ptr=0
> dma_st=0 dma_ct=0 n_msgout=0
> target 0: req=ef8501e0 goes_out=0 saved_ptr=0
> mesh_host_reset
> mesh_abort(ef8501e0)
> mesh: state at ef9eaa50, regs at f1010000, dma at f1014a00
> ct= 0 seq=6a bs=4026 fc= 5 exc= 0 err= 0 im= 7 int= 0 sp= 2
> fifo data=c0
> fifo data=01
> fifo data=03
> fifo data=01
> fifo data=19
> dma stat=e0 cmdptr=2f8c2010
> phase=3 msgphase=1 conn_tgt=0 data_ptr=0
> dma_st=0 dma_ct=0 n_msgout=6
> target 0: req=ef8501e0 goes_out=0 saved_ptr=0
> mesh_host_reset
> ...
> [afterwards, it "disconnects" all the disks and then it panics as it
> cannot find the root partition]
>
> 2.6.29 runs fine ... but I guess that at some point, I would like to
> upgrade to the latest stable kernel.
>
> The machine is a PowerPC9600 with a 740 upgrade card, 1GB memory,
> kernel compiled with GCC 4.3.4 ...
>
> Of course I am willing to offer you all assistance you need to help
> you pin-point the problem...
>
> Thanks for your help
>
> Stef
>
> Stef Simoens schreef:
> > Hello Ben,
> >
> > Thank you for your reply.
> >
> > > On Fri, 2009-07-24 at 00:18 +0200, Stef Simoens wrote:
> > >
> > > > I tried the latest 2.6.31-rc3-git3 (without any other patch).
> > > > However, I have the same behaviour as the patched 2.6.30 (so: no BUG,
> > > > but the mesh_abort messages).
> > > >
> > > Would it be possible for you to roughly find out at what kernel version
> > > it stopped working ? (Some kernels may need my patch to avoid crashing)
> > >
> >
> > I am currently running 2.6.29-gentoo-r5 (that's somewhere at the end of
> > 2.6.29, probably 2.6.29.5).
> >
> > I compiled 2.6.30 as soon as it came 'stable'.
> > In any version of 2.6.30, I encounter the BUG (dma-mapping.h:218).
> >
> > I didn't react immediately, I actually guessed that the problem would have
> > been reported and solved in another 2.6.30.x.
> > Because it didn't, I started browsing the mailing-list (and found your
> > patch).
> > 2.6.30-gentoo-r3 with your patch applied doesn't give the bug,
> > but gives the mesh_abort.
> >
> > Before asking the question, I wanted to build the latest 2.6.31-rc
> > available to make sure my problem didn't get solved in the meantime.
> > 2.6.31-rc3 gives the same mesh_abort.
> >
> > Would you like me to try all the linux-2.6.30-rc?
> > Could you give me your best guess starting-point?
> >
> > I know that there exists something as git-disect ... but I have never used
> > git (there always needs to be the first time, of course).
> >
> > Kind regards,
> >
> > Stef
> >
> --
> Stef Simoens stef.simoens@numericable.be
> +32 486 577 963 http://users.numericable.be/stef
^ permalink raw reply
* Re: [PATCH 4/6] powerpc: Rename LWSYNC_ON_SMP to PPC_RELEASE_BARRIER, ISYNC_ON_SMP to PPC_ACQUIRE_BARRIER
From: Nick Piggin @ 2010-03-19 1:08 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev
In-Reply-To: <20100210110406.GD3399@kryten>
On Wed, Feb 10, 2010 at 10:04:06PM +1100, Anton Blanchard wrote:
>
> For performance reasons we are about to change ISYNC_ON_SMP to sometimes be
> lwsync. Now that the macro name doesn't make sense, change it and LWSYNC_ON_SMP
> to better explain what the barriers are doing.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
> ---
>
> Index: powerpc.git/arch/powerpc/include/asm/atomic.h
> ===================================================================
> --- powerpc.git.orig/arch/powerpc/include/asm/atomic.h 2010-02-10 17:12:30.264322204 +1100
> +++ powerpc.git/arch/powerpc/include/asm/atomic.h 2010-02-10 17:13:05.355571902 +1100
> @@ -49,13 +49,13 @@ static __inline__ int atomic_add_return(
> int t;
>
> __asm__ __volatile__(
> - LWSYNC_ON_SMP
> + PPC_RELEASE_BARRIER
> "1: lwarx %0,0,%2 # atomic_add_return\n\
> add %0,%1,%0\n"
> PPC405_ERR77(0,%2)
> " stwcx. %0,0,%2 \n\
> bne- 1b"
> - ISYNC_ON_SMP
> + PPC_ACQUIRE_BARRIER
I wonder if this shouldn't be called PPC_ISYNC_ACQUIRE_BARRIER ?
Unlike PPC_RELEASE_BARRIER, it is not an acquire barrier unless it
is used like an isync.
^ permalink raw reply
* [PATCH v3 0/9] wireless: Use macros from wireless.h
From: Joe Perches @ 2010-03-19 1:29 UTC (permalink / raw)
To: linux-kernel
Cc: orinoco-users, Zhu Yi, Reinette Chatre, David Gibson, netdev,
orinoco-devel, linux-wireless, cbe-oss-dev, Intel Linux Wireless,
linuxppc-dev, Arnaldo Carvalho de Melo, Johannes Berg,
Richard Kennedy, David S. Miller, Pavel Roskin
Create a IW_HANDLER macro for iw_handler array entries in wireless.h
Use the wireless.h macros in various wireless files
Use starting index define SIOCIWFIRST where appropriate
Remove local #defines of IW_IOCTL
Remove STD_IW_HANDLER macro in orinoco, use IW_HANDLER instead
Joe Perches (9):
include/linux/wireless.h: Add IW_HANDLER macro to initialize array entry
wireless.h: Use SIOCIWFIRST not SIOCSIWCOMMIT for range check
include/net/iw_handler.h: Use SIOCIWFIRST not SIOCSIWCOMMIT in comment
net/wireless/wext_core.c: Use IW_IOCTL_IDX macro
net/wireless/wext-core.c: Use IW_EVENT_IDX macro
drivers/net/wireless: Use IW_HANDLER macro
drivers/net: Remove local #define IW_IOCTL, use IW_HANDLER
orinoco/wext.c: Remove local #define STD_IW_HANDLER
drivers/net/wireless/ray_cs.c: Use iw_handler function prototypes
drivers/net/ps3_gelic_wireless.c | 35 +++---
drivers/net/wireless/ipw2x00/ipw2200.c | 83 ++++++-------
drivers/net/wireless/orinoco/wext.c | 94 +++++++-------
drivers/net/wireless/ray_cs.c | 212 +++++++++++++++-----------------
drivers/net/wireless/wl3501_cs.c | 52 ++++----
include/linux/wireless.h | 4 +-
include/net/iw_handler.h | 2 +-
net/wireless/wext-core.c | 134 ++++++++++----------
8 files changed, 298 insertions(+), 318 deletions(-)
^ permalink raw reply
* [PATCH v3 7/9] drivers/net: Remove local #define IW_IOCTL, use IW_HANDLER
From: Joe Perches @ 2010-03-19 1:29 UTC (permalink / raw)
To: linux-kernel
Cc: Zhu Yi, Reinette Chatre, netdev, linux-wireless,
Intel Linux Wireless, linuxppc-dev, Johannes Berg,
Richard Kennedy, cbe-oss-dev
In-Reply-To: <cover.1268961559.git.joe@perches.com>
Use #define IW_HANDLER from wireless.h instead
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/ps3_gelic_wireless.c | 35 +++++++-------
drivers/net/wireless/ipw2x00/ipw2200.c | 83 ++++++++++++++++----------------
2 files changed, 58 insertions(+), 60 deletions(-)
diff --git a/drivers/net/ps3_gelic_wireless.c b/drivers/net/ps3_gelic_wireless.c
index 2663b2f..f5fc0f7 100644
--- a/drivers/net/ps3_gelic_wireless.c
+++ b/drivers/net/ps3_gelic_wireless.c
@@ -2279,26 +2279,25 @@ void gelic_wl_interrupt(struct net_device *netdev, u64 status)
/*
* driver helpers
*/
-#define IW_IOCTL(n) [(n) - SIOCSIWCOMMIT]
static const iw_handler gelic_wl_wext_handler[] =
{
- IW_IOCTL(SIOCGIWNAME) = gelic_wl_get_name,
- IW_IOCTL(SIOCGIWRANGE) = gelic_wl_get_range,
- IW_IOCTL(SIOCSIWSCAN) = gelic_wl_set_scan,
- IW_IOCTL(SIOCGIWSCAN) = gelic_wl_get_scan,
- IW_IOCTL(SIOCSIWAUTH) = gelic_wl_set_auth,
- IW_IOCTL(SIOCGIWAUTH) = gelic_wl_get_auth,
- IW_IOCTL(SIOCSIWESSID) = gelic_wl_set_essid,
- IW_IOCTL(SIOCGIWESSID) = gelic_wl_get_essid,
- IW_IOCTL(SIOCSIWENCODE) = gelic_wl_set_encode,
- IW_IOCTL(SIOCGIWENCODE) = gelic_wl_get_encode,
- IW_IOCTL(SIOCSIWAP) = gelic_wl_set_ap,
- IW_IOCTL(SIOCGIWAP) = gelic_wl_get_ap,
- IW_IOCTL(SIOCSIWENCODEEXT) = gelic_wl_set_encodeext,
- IW_IOCTL(SIOCGIWENCODEEXT) = gelic_wl_get_encodeext,
- IW_IOCTL(SIOCSIWMODE) = gelic_wl_set_mode,
- IW_IOCTL(SIOCGIWMODE) = gelic_wl_get_mode,
- IW_IOCTL(SIOCGIWNICKN) = gelic_wl_get_nick,
+ IW_HANDLER(SIOCGIWNAME, gelic_wl_get_name),
+ IW_HANDLER(SIOCGIWRANGE, gelic_wl_get_range),
+ IW_HANDLER(SIOCSIWSCAN, gelic_wl_set_scan),
+ IW_HANDLER(SIOCGIWSCAN, gelic_wl_get_scan),
+ IW_HANDLER(SIOCSIWAUTH, gelic_wl_set_auth),
+ IW_HANDLER(SIOCGIWAUTH, gelic_wl_get_auth),
+ IW_HANDLER(SIOCSIWESSID, gelic_wl_set_essid),
+ IW_HANDLER(SIOCGIWESSID, gelic_wl_get_essid),
+ IW_HANDLER(SIOCSIWENCODE, gelic_wl_set_encode),
+ IW_HANDLER(SIOCGIWENCODE, gelic_wl_get_encode),
+ IW_HANDLER(SIOCSIWAP, gelic_wl_set_ap),
+ IW_HANDLER(SIOCGIWAP, gelic_wl_get_ap),
+ IW_HANDLER(SIOCSIWENCODEEXT, gelic_wl_set_encodeext),
+ IW_HANDLER(SIOCGIWENCODEEXT, gelic_wl_get_encodeext),
+ IW_HANDLER(SIOCSIWMODE, gelic_wl_set_mode),
+ IW_HANDLER(SIOCGIWMODE, gelic_wl_get_mode),
+ IW_HANDLER(SIOCGIWNICKN, gelic_wl_get_nick),
};
static const struct iw_handler_def gelic_wl_wext_handler_def = {
diff --git a/drivers/net/wireless/ipw2x00/ipw2200.c b/drivers/net/wireless/ipw2x00/ipw2200.c
index 5c7aa1b..9e9c532 100644
--- a/drivers/net/wireless/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/ipw2x00/ipw2200.c
@@ -9995,49 +9995,48 @@ static int ipw_wx_sw_reset(struct net_device *dev,
}
/* Rebase the WE IOCTLs to zero for the handler array */
-#define IW_IOCTL(x) [(x)-SIOCSIWCOMMIT]
static iw_handler ipw_wx_handlers[] = {
- IW_IOCTL(SIOCGIWNAME) = (iw_handler) cfg80211_wext_giwname,
- IW_IOCTL(SIOCSIWFREQ) = ipw_wx_set_freq,
- IW_IOCTL(SIOCGIWFREQ) = ipw_wx_get_freq,
- IW_IOCTL(SIOCSIWMODE) = ipw_wx_set_mode,
- IW_IOCTL(SIOCGIWMODE) = ipw_wx_get_mode,
- IW_IOCTL(SIOCSIWSENS) = ipw_wx_set_sens,
- IW_IOCTL(SIOCGIWSENS) = ipw_wx_get_sens,
- IW_IOCTL(SIOCGIWRANGE) = ipw_wx_get_range,
- IW_IOCTL(SIOCSIWAP) = ipw_wx_set_wap,
- IW_IOCTL(SIOCGIWAP) = ipw_wx_get_wap,
- IW_IOCTL(SIOCSIWSCAN) = ipw_wx_set_scan,
- IW_IOCTL(SIOCGIWSCAN) = ipw_wx_get_scan,
- IW_IOCTL(SIOCSIWESSID) = ipw_wx_set_essid,
- IW_IOCTL(SIOCGIWESSID) = ipw_wx_get_essid,
- IW_IOCTL(SIOCSIWNICKN) = ipw_wx_set_nick,
- IW_IOCTL(SIOCGIWNICKN) = ipw_wx_get_nick,
- IW_IOCTL(SIOCSIWRATE) = ipw_wx_set_rate,
- IW_IOCTL(SIOCGIWRATE) = ipw_wx_get_rate,
- IW_IOCTL(SIOCSIWRTS) = ipw_wx_set_rts,
- IW_IOCTL(SIOCGIWRTS) = ipw_wx_get_rts,
- IW_IOCTL(SIOCSIWFRAG) = ipw_wx_set_frag,
- IW_IOCTL(SIOCGIWFRAG) = ipw_wx_get_frag,
- IW_IOCTL(SIOCSIWTXPOW) = ipw_wx_set_txpow,
- IW_IOCTL(SIOCGIWTXPOW) = ipw_wx_get_txpow,
- IW_IOCTL(SIOCSIWRETRY) = ipw_wx_set_retry,
- IW_IOCTL(SIOCGIWRETRY) = ipw_wx_get_retry,
- IW_IOCTL(SIOCSIWENCODE) = ipw_wx_set_encode,
- IW_IOCTL(SIOCGIWENCODE) = ipw_wx_get_encode,
- IW_IOCTL(SIOCSIWPOWER) = ipw_wx_set_power,
- IW_IOCTL(SIOCGIWPOWER) = ipw_wx_get_power,
- IW_IOCTL(SIOCSIWSPY) = iw_handler_set_spy,
- IW_IOCTL(SIOCGIWSPY) = iw_handler_get_spy,
- IW_IOCTL(SIOCSIWTHRSPY) = iw_handler_set_thrspy,
- IW_IOCTL(SIOCGIWTHRSPY) = iw_handler_get_thrspy,
- IW_IOCTL(SIOCSIWGENIE) = ipw_wx_set_genie,
- IW_IOCTL(SIOCGIWGENIE) = ipw_wx_get_genie,
- IW_IOCTL(SIOCSIWMLME) = ipw_wx_set_mlme,
- IW_IOCTL(SIOCSIWAUTH) = ipw_wx_set_auth,
- IW_IOCTL(SIOCGIWAUTH) = ipw_wx_get_auth,
- IW_IOCTL(SIOCSIWENCODEEXT) = ipw_wx_set_encodeext,
- IW_IOCTL(SIOCGIWENCODEEXT) = ipw_wx_get_encodeext,
+ IW_HANDLER(SIOCGIWNAME, (iw_handler)cfg80211_wext_giwname),
+ IW_HANDLER(SIOCSIWFREQ, ipw_wx_set_freq),
+ IW_HANDLER(SIOCGIWFREQ, ipw_wx_get_freq),
+ IW_HANDLER(SIOCSIWMODE, ipw_wx_set_mode),
+ IW_HANDLER(SIOCGIWMODE, ipw_wx_get_mode),
+ IW_HANDLER(SIOCSIWSENS, ipw_wx_set_sens),
+ IW_HANDLER(SIOCGIWSENS, ipw_wx_get_sens),
+ IW_HANDLER(SIOCGIWRANGE, ipw_wx_get_range),
+ IW_HANDLER(SIOCSIWAP, ipw_wx_set_wap),
+ IW_HANDLER(SIOCGIWAP, ipw_wx_get_wap),
+ IW_HANDLER(SIOCSIWSCAN, ipw_wx_set_scan),
+ IW_HANDLER(SIOCGIWSCAN, ipw_wx_get_scan),
+ IW_HANDLER(SIOCSIWESSID, ipw_wx_set_essid),
+ IW_HANDLER(SIOCGIWESSID, ipw_wx_get_essid),
+ IW_HANDLER(SIOCSIWNICKN, ipw_wx_set_nick),
+ IW_HANDLER(SIOCGIWNICKN, ipw_wx_get_nick),
+ IW_HANDLER(SIOCSIWRATE, ipw_wx_set_rate),
+ IW_HANDLER(SIOCGIWRATE, ipw_wx_get_rate),
+ IW_HANDLER(SIOCSIWRTS, ipw_wx_set_rts),
+ IW_HANDLER(SIOCGIWRTS, ipw_wx_get_rts),
+ IW_HANDLER(SIOCSIWFRAG, ipw_wx_set_frag),
+ IW_HANDLER(SIOCGIWFRAG, ipw_wx_get_frag),
+ IW_HANDLER(SIOCSIWTXPOW, ipw_wx_set_txpow),
+ IW_HANDLER(SIOCGIWTXPOW, ipw_wx_get_txpow),
+ IW_HANDLER(SIOCSIWRETRY, ipw_wx_set_retry),
+ IW_HANDLER(SIOCGIWRETRY, ipw_wx_get_retry),
+ IW_HANDLER(SIOCSIWENCODE, ipw_wx_set_encode),
+ IW_HANDLER(SIOCGIWENCODE, ipw_wx_get_encode),
+ IW_HANDLER(SIOCSIWPOWER, ipw_wx_set_power),
+ IW_HANDLER(SIOCGIWPOWER, ipw_wx_get_power),
+ IW_HANDLER(SIOCSIWSPY, iw_handler_set_spy),
+ IW_HANDLER(SIOCGIWSPY, iw_handler_get_spy),
+ IW_HANDLER(SIOCSIWTHRSPY, iw_handler_set_thrspy),
+ IW_HANDLER(SIOCGIWTHRSPY, iw_handler_get_thrspy),
+ IW_HANDLER(SIOCSIWGENIE, ipw_wx_set_genie),
+ IW_HANDLER(SIOCGIWGENIE, ipw_wx_get_genie),
+ IW_HANDLER(SIOCSIWMLME, ipw_wx_set_mlme),
+ IW_HANDLER(SIOCSIWAUTH, ipw_wx_set_auth),
+ IW_HANDLER(SIOCGIWAUTH, ipw_wx_get_auth),
+ IW_HANDLER(SIOCSIWENCODEEXT, ipw_wx_set_encodeext),
+ IW_HANDLER(SIOCGIWENCODEEXT, ipw_wx_get_encodeext),
};
enum {
--
1.7.0.14.g7e948
^ permalink raw reply related
* Re: [PATCH 4/6] powerpc: Rename LWSYNC_ON_SMP to PPC_RELEASE_BARRIER, ISYNC_ON_SMP to PPC_ACQUIRE_BARRIER
From: Benjamin Herrenschmidt @ 2010-03-19 1:36 UTC (permalink / raw)
To: Nick Piggin; +Cc: linuxppc-dev, Anton Blanchard
In-Reply-To: <20100319010813.GF25636@laptop>
On Fri, 2010-03-19 at 12:08 +1100, Nick Piggin wrote:
> > - ISYNC_ON_SMP
> > + PPC_ACQUIRE_BARRIER
>
> I wonder if this shouldn't be called PPC_ISYNC_ACQUIRE_BARRIER ?
>
> Unlike PPC_RELEASE_BARRIER, it is not an acquire barrier unless it
> is used like an isync.
Right. The semantic of isync would be more something like
PPC_IFETCH_BARRIER or similar :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc/fsl: Add multiple MSI bank support
From: Michael Ellerman @ 2010-03-19 3:06 UTC (permalink / raw)
To: Kumar Gala; +Cc: Lan Chunhe-B25806, linuxppc-dev
In-Reply-To: <1268923993-26689-1-git-send-email-galak@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1738 bytes --]
On Thu, 2010-03-18 at 09:53 -0500, Kumar Gala wrote:
> From: Lan Chunhe-B25806 <B25806@freescale.com>
>
> Freescale QorIQ P4080 has three MSI banks and the original code
> can not work well. This patch adds multiple MSI banks support for
> Freescale processor.
>
> Signed-off-by: Lan Chunhe-B25806 <b25806@freescale.com>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> @@ -146,9 +149,13 @@ static int fsl_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
> unsigned int virq;
> struct msi_desc *entry;
> struct msi_msg msg;
> - struct fsl_msi *msi_data = fsl_msi;
> + struct fsl_msi *msi_data;
>
> list_for_each_entry(entry, &pdev->msi_list, list) {
> + if (entry->irq == NO_IRQ)
> + continue;
This looks wrong, entry->irq should always be 0 here because it was just
kzalloc'ed - you should only be doing this check in teardown.
> - WARN_ON(ppc_md.setup_msi_irqs);
> - ppc_md.setup_msi_irqs = fsl_setup_msi_irqs;
> - ppc_md.teardown_msi_irqs = fsl_teardown_msi_irqs;
> - ppc_md.msi_check_device = fsl_msi_check_device;
> + /* The multiple setting ppc_md.setup_msi_irqs will not harm things */
> + if (!ppc_md.setup_msi_irqs) {
> + ppc_md.setup_msi_irqs = fsl_setup_msi_irqs;
> + ppc_md.teardown_msi_irqs = fsl_teardown_msi_irqs;
> + ppc_md.msi_check_device = fsl_msi_check_device;
> + } else if (ppc_md.setup_msi_irqs != fsl_setup_msi_irqs) {
> + dev_err(&dev->dev, "Different MSI driver already installed!\n");
> + err = -EBUSY; /* or some other error code */
> + goto error_out;
> + }
I liked it the way it was, because having two competing MSI backends
means something's probably not going to work. But it's your driver so
whatever you like.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] PPC: Skip over OF_DT_NOP when unflattening the device tree
From: Benjamin Herrenschmidt @ 2010-03-19 5:50 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20100309193021.GD30462@obsidianresearch.com>
On Tue, 2010-03-09 at 12:30 -0700, Jason Gunthorpe wrote:
> NOPs within the property section are skipped, but NOPs between
> OF_DT_END_NODE and OF_DT_BEGIN_NODE were not. My firmware NOPs out
> entire nodes depending on various environment parameters.
>
> of_scan_flat_dt already handles NOP more generally..
Good catch, though that code has now moved over to drivers/of
and is a bit different. Grant is going to fix it up though.
Cheers,
Ben.
> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
> ---
> arch/powerpc/kernel/prom.c | 7 +++++--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> index 4ec3008..92137b2 100644
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -408,8 +408,11 @@ static unsigned long __init unflatten_dt_node(unsigned long mem,
> if (!np->type)
> np->type = "<NULL>";
> }
> - while (tag == OF_DT_BEGIN_NODE) {
> - mem = unflatten_dt_node(mem, p, np, allnextpp, fpsize);
> + while (tag == OF_DT_BEGIN_NODE || tag == OF_DT_NOP) {
> + if (tag == OF_DT_NOP)
> + *p += 4;
> + else
> + mem = unflatten_dt_node(mem, p, np, allnextpp, fpsize);
> tag = *((u32 *)(*p));
> }
> if (tag != OF_DT_END_NODE) {
^ permalink raw reply
* Re: [PATCH] PPC: Skip over OF_DT_NOP when unflattening the device tree
From: Jason Gunthorpe @ 2010-03-19 6:06 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1268977838.8599.53.camel@pasglop>
On Fri, Mar 19, 2010 at 04:50:38PM +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2010-03-09 at 12:30 -0700, Jason Gunthorpe wrote:
> > NOPs within the property section are skipped, but NOPs between
> > OF_DT_END_NODE and OF_DT_BEGIN_NODE were not. My firmware NOPs out
> > entire nodes depending on various environment parameters.
> >
> > of_scan_flat_dt already handles NOP more generally..
>
> Good catch, though that code has now moved over to drivers/of
> and is a bit different. Grant is going to fix it up though.
Ah, I based the patch off 2.6.33..
Grant: let me know if you need some help/testing, nice to run into you
again.
Jason
^ permalink raw reply
* Re: [PATCH] PPC: Skip over OF_DT_NOP when unflattening the device tree
From: Grant Likely @ 2010-03-19 6:18 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: linux-kernel, linuxppc-dev
In-Reply-To: <20100319060621.GC28042@obsidianresearch.com>
On Fri, Mar 19, 2010 at 12:06 AM, Jason Gunthorpe
<jgunthorpe@obsidianresearch.com> wrote:
> On Fri, Mar 19, 2010 at 04:50:38PM +1100, Benjamin Herrenschmidt wrote:
>> On Tue, 2010-03-09 at 12:30 -0700, Jason Gunthorpe wrote:
>> > NOPs within the property section are skipped, but NOPs between
>> > OF_DT_END_NODE and OF_DT_BEGIN_NODE were not. My firmware NOPs out
>> > entire nodes depending on various environment parameters.
>> >
>> > of_scan_flat_dt already handles NOP more generally..
>>
>> Good catch, though that code has now moved over to drivers/of
>> and is a bit different. Grant is going to fix it up though.
>
> Ah, I based the patch off 2.6.33..
>
> Grant: let me know if you need some help/testing, nice to run into you
> again.
Would be nice if you could respin and test your patch against 2.6.34-rc1. :-)
Otherwise I'll look at it tomorrow.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2010-03-19 7:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
Here's a handful of powerpc fixes for 2.6.34, along with a patch
from Fujita Tomonori to remove a config option that is mostly
useless nowadays.
Cheers,
Ben.
The following changes since commit 39710479303fd3affb3e204e9a7a75cc676977b5:
Linus Torvalds (1):
Merge branch 'for-linus' of git://git.kernel.org/.../vapier/blackfin
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Benjamin Herrenschmidt (1):
Merge commit 'kumar/merge' into merge
FUJITA Tomonori (2):
powerpc: Fix swiotlb to respect the boot option
powerpc: Remove IOMMU_VMERGE config option
Kumar Gala (2):
powerpc/85xx: Make sure lwarx hint isn't set on ppc32
powerpc/fsl-booke: Get coherent bit from PTE
Márton Németh (1):
powerpc: Do not call prink when CONFIG_PRINTK is not defined
Nathan Lynch (1):
powerpc: Use correct ccr bit for syscall error status
arch/powerpc/Kconfig | 13 -------------
arch/powerpc/include/asm/ppc-opcode.h | 6 +++---
arch/powerpc/include/asm/syscall.h | 6 +++---
arch/powerpc/kernel/head_fsl_booke.S | 7 ++++---
arch/powerpc/kernel/iommu.c | 7 +------
arch/powerpc/kernel/setup_32.c | 6 ------
arch/powerpc/kernel/setup_64.c | 6 ------
arch/powerpc/mm/mem.c | 6 ++++++
8 files changed, 17 insertions(+), 40 deletions(-)
^ permalink raw reply
* BestComm BD tasks, buffer done flag question
From: Roman Fietze @ 2010-03-19 8:15 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I'm using Grant's platform SCLPC/BestComm driver to transfer data from
an FPGA (to disk). Very often I get a negative result from
bcom_buffer_done because BCOM_BD_READY is not set.
When searching for a solution I found this mail from Rob Broersen
talking about a similar promlem in the MPC5200's FEC interrupt
handler:
http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg16324.html
When I now do something ugly like
if (!bcom_buffer_done(lpbfifo->bcom_cur_task))
mdelay(1);
/* retry */
if (!bcom_buffer_done(lpbfifo->bcom_cur_task)) {
ERROR!!!
return IRQ_HANDLED;
}
HANDLE BD
in the ISR I always succeed, even in the cases where the first check
fails and I call the mdelay. Before that I very often ran into the
ERROR!!! case and my transfer "failed".
Is there a better solution? Does the FEC interrupt handler really work
fine as it is right now? I ask, because when I assume that there would
be just one active DB (as it always is with the SCLPC platform driver)
this one would evt. stall if there wasn't a second interrupt causing
the loop to handle it in this second interrupt.
Roman
=2D-=20
Roman Fietze Telemotive AG B=FCro M=FChlhausen
Breitwiesen 73347 M=FChlhausen
Tel.: +49(0)7335/18493-45 http://www.telemotive.de
^ permalink raw reply
* [PATCH]: Minor quibble in macintosh/windfarm_pm81.c
From: d binderman @ 2010-03-19 9:01 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 824 bytes --]
Hello there,
I just ran the sourceforge tool cppcheck over the source code of the
new Linux kernel 2.6.34-rc1
It said
[./macintosh/windfarm_pm81.c:760]: (style) Redundant condition. It is safe to deallocate a NULL poin
ter
[./macintosh/windfarm_pm81.c:762]: (style) Redundant condition. It is safe to deallocate a NULL poin
ter
The source code is
/* Destroy control loops state structures */
if (wf_smu_sys_fans)
kfree(wf_smu_sys_fans);
if (wf_smu_cpu_fans)
kfree(wf_smu_cpu_fans);
Proposed patch file attached.
Regards
David Binderman
_________________________________________________________________
Send us your Hotmail stories and be featured in our newsletter
http://clk.atdmt.com/UKM/go/195013117/direct/01/
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: bug39.patch --]
[-- Type: text/x-patch, Size: 504 bytes --]
Signed-off-by: David Binderman <dcb314@hotmail.com>
--- macintosh/windfarm_pm81.c.sav 2010-03-19 08:57:22.000000000 +0000
+++ macintosh/windfarm_pm81.c 2010-03-19 08:57:34.000000000 +0000
@@ -757,10 +757,8 @@ static int __devexit wf_smu_remove(struc
wf_put_control(cpufreq_clamp);
/* Destroy control loops state structures */
- if (wf_smu_sys_fans)
- kfree(wf_smu_sys_fans);
- if (wf_smu_cpu_fans)
- kfree(wf_smu_cpu_fans);
+ kfree(wf_smu_sys_fans);
+ kfree(wf_smu_cpu_fans);
return 0;
}
^ permalink raw reply
* [PATCH]: core/gpio-pmf.c: 3 * redundant code
From: d binderman @ 2010-03-19 10:12 UTC (permalink / raw)
To: johannes; +Cc: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 199 bytes --]
_________________________________________________________________
Send us your Hotmail stories and be featured in our newsletter
http://clk.atdmt.com/UKM/go/195013117/direct/01/
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: bug45.patch --]
[-- Type: text/x-patch, Size: 764 bytes --]
Signed-off-by: David Binderman <dcb314@hotmail.com>
--- aoa/core/gpio-pmf.c.sav 2010-03-19 10:07:30.000000000 +0000
+++ aoa/core/gpio-pmf.c 2010-03-19 10:07:40.000000000 +0000
@@ -115,12 +115,9 @@ static void pmf_gpio_exit(struct gpio_ru
mutex_destroy(&rt->line_in_notify.mutex);
mutex_destroy(&rt->line_out_notify.mutex);
- if (rt->headphone_notify.gpio_private)
- kfree(rt->headphone_notify.gpio_private);
- if (rt->line_in_notify.gpio_private)
- kfree(rt->line_in_notify.gpio_private);
- if (rt->line_out_notify.gpio_private)
- kfree(rt->line_out_notify.gpio_private);
+ kfree(rt->headphone_notify.gpio_private);
+ kfree(rt->line_in_notify.gpio_private);
+ kfree(rt->line_out_notify.gpio_private);
}
static void pmf_handle_notify_irq(void *data)
^ permalink raw reply
* [GITPULL+PATCH 0/2 v3] irq: move some interrupt arch_* functions into struct irq_chip.
From: Ian Campbell @ 2010-03-19 11:27 UTC (permalink / raw)
To: linux-kernel
Cc: Jeremy Fitzhardinge, Ian Campbell, Paul Mundt, linux-sh,
x86@kernel.org, linuxppc-dev@ozlabs.org, Ingo Molnar,
Paul Mackerras, H. Peter Anvin, Thomas Gleixner, Yinghai Lu
This small series ensures that struct irq_desc->chip_data is available
for alternative irq_chip implementations.
Since v2: pass x86_init_chip_data as a argument to
irq_to_desc_alloc_node instead of calling in the arch code in order to
get correct locking wrt the core code. Small impact on the SH arch code
which is the only other user outside x86 and powerpc.
Since v1: dropped the renaming portion of the series since it
was basically wrong, the functions I'd implicated as ioapic specific are
not at all.
Ian.
The following changes since commit 1ebbdcc83e75697c0d75eb091df172b7d93c84c1:
Ingo Molnar (1):
Merge branch 'perf/urgent'
are available in the git repository at:
git://xenbits.xensource.com/people/ianc/linux-2.6.git for-x86/irq
Ian Campbell (2):
irq: move some interrupt arch_* functions into struct irq_chip.
x86: irq_desc->chip_data is always correct whether or not SPARSE_IRQ is enabled.
arch/powerpc/kernel/irq.c | 4 +-
arch/sh/kernel/cpu/irq/ipr.c | 2 +-
arch/x86/include/asm/hw_irq.h | 11 ++++++-
arch/x86/kernel/apic/io_apic.c | 67 ++++++++++++++++++++++++++++++++--------
arch/x86/kernel/uv_irq.c | 5 +++
arch/x86/lguest/boot.c | 2 +-
drivers/sh/intc.c | 7 ++--
drivers/xen/events.c | 2 +-
include/linux/interrupt.h | 2 +-
include/linux/irq.h | 16 ++++++---
kernel/irq/handle.c | 15 ++++++---
kernel/irq/numa_migrate.c | 12 ++++++-
kernel/softirq.c | 3 +-
13 files changed, 111 insertions(+), 37 deletions(-)
^ permalink raw reply
* [PATCH 1/2] irq: move some interrupt arch_* functions into struct irq_chip.
From: Ian Campbell @ 2010-03-19 11:27 UTC (permalink / raw)
To: linux-kernel
Cc: Jeremy Fitzhardinge, Rusty Russell, Ian Campbell, Paul Mundt,
linux-sh, x86, lguest, linuxppc-dev, Ingo Molnar, Paul Mackerras,
Eric W. Biederman, H. Peter Anvin, Thomas Gleixner, Yinghai Lu
In-Reply-To: <1268998032.10129.44653.camel@zakaz.uk.xensource.com>
Move arch_init_copy_chip_data and arch_free_chip_data into function
pointers in struct irq_chip since they operate on irq_desc->chip_data.
arch_init_chip_data cannot be moved into struct irq_chip because
irq_desc->chip is not known at the time the irq_desc is setup. Instead
rename arch_init_chip_data to arch_init_irq_desc for PowerPC, the
only other user, whose usage better matches the new name.
To replace the x86 arch_init_chip_data functionality
irq_to_desc_alloc_node now takes a pointer to a function to allocate
the chip data. This is necessary to ensure the allocation happens
under the correct locking at the core level. On PowerPC and SH
architectures (the other users of irq_to_desc_alloc_node) pass in NULL
which retains existing chip_data behaviour.
I've retained the chip_data behaviour for uv_irq although it isn't
clear to me if these interrupt types support migration or how closely
related to the APIC modes they really are. If it weren't for this the
x86_{init,copy,free}_chip_data functions could be static to
io_apic.c.
I've tested by booting on an 64 bit x86 system with sparse IRQ enabled
and 32 bit without, but it's not clear to me what actions I need to
take to actually exercise some of these code paths.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Michael Ellerman <michael@ellerman.id.au> [PowerPC rename portion]
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: x86@kernel.org
Cc: linuxppc-dev@ozlabs.org
Cc: linux-kernel@vger.kernel.org
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: lguest@ozlabs.org
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: linux-sh@vger.kernel.org
---
arch/powerpc/kernel/irq.c | 4 +-
arch/sh/kernel/cpu/irq/ipr.c | 2 +-
arch/x86/include/asm/hw_irq.h | 11 ++++++-
arch/x86/kernel/apic/io_apic.c | 64 ++++++++++++++++++++++++++++++++++-----
arch/x86/kernel/uv_irq.c | 5 +++
arch/x86/lguest/boot.c | 2 +-
drivers/sh/intc.c | 7 ++--
drivers/xen/events.c | 2 +-
include/linux/interrupt.h | 2 +-
include/linux/irq.h | 16 +++++++---
kernel/irq/handle.c | 15 ++++++---
kernel/irq/numa_migrate.c | 12 ++++++-
kernel/softirq.c | 3 +-
13 files changed, 112 insertions(+), 33 deletions(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 64f6f20..dc5a8c1 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -670,7 +670,7 @@ static int irq_setup_virq(struct irq_host *host, unsigned int virq,
{
struct irq_desc *desc;
- desc = irq_to_desc_alloc_node(virq, 0);
+ desc = irq_to_desc_alloc_node(virq, 0, NULL);
if (!desc) {
pr_debug("irq: -> allocating desc failed\n");
goto error;
@@ -1088,7 +1088,7 @@ int arch_early_irq_init(void)
return 0;
}
-int arch_init_chip_data(struct irq_desc *desc, int node)
+int arch_init_irq_desc(struct irq_desc *desc, int node)
{
desc->status |= IRQ_NOREQUEST;
return 0;
diff --git a/arch/sh/kernel/cpu/irq/ipr.c b/arch/sh/kernel/cpu/irq/ipr.c
index 9282d96..cf31454 100644
--- a/arch/sh/kernel/cpu/irq/ipr.c
+++ b/arch/sh/kernel/cpu/irq/ipr.c
@@ -67,7 +67,7 @@ void register_ipr_controller(struct ipr_desc *desc)
BUG_ON(p->ipr_idx >= desc->nr_offsets);
BUG_ON(!desc->ipr_offsets[p->ipr_idx]);
- irq_desc = irq_to_desc_alloc_node(p->irq, numa_node_id());
+ irq_desc = irq_to_desc_alloc_node(p->irq, numa_node_id(), NULL);
if (unlikely(!irq_desc)) {
printk(KERN_INFO "can not get irq_desc for %d\n",
p->irq);
diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h
index a929c9e..1bc7063 100644
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -20,9 +20,9 @@
#include <linux/percpu.h>
#include <linux/profile.h>
#include <linux/smp.h>
+#include <linux/irq.h>
#include <asm/atomic.h>
-#include <asm/irq.h>
#include <asm/sections.h>
/* Interrupt handlers registered during init_IRQ */
@@ -61,6 +61,15 @@ extern void init_VISWS_APIC_irqs(void);
extern void setup_IO_APIC(void);
extern void disable_IO_APIC(void);
+extern int x86_init_chip_data(struct irq_desc *desc, int node);
+
+#ifdef CONFIG_SPARSE_IRQ
+extern void x86_copy_chip_data(struct irq_desc *old_desc,
+ struct irq_desc *desc, int node);
+extern void x86_free_chip_data(struct irq_desc *old_desc,
+ struct irq_desc *desc);
+#endif
+
struct io_apic_irq_attr {
int ioapic;
int ioapic_pin;
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index e4e0ddc..035b6d2 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -211,7 +211,7 @@ static struct irq_cfg *get_one_free_irq_cfg(int node)
return cfg;
}
-int arch_init_chip_data(struct irq_desc *desc, int node)
+int x86_init_chip_data(struct irq_desc *desc, int node)
{
struct irq_cfg *cfg;
@@ -287,8 +287,8 @@ static void free_irq_2_pin(struct irq_cfg *old_cfg, struct irq_cfg *cfg)
old_cfg->irq_2_pin = NULL;
}
-void arch_init_copy_chip_data(struct irq_desc *old_desc,
- struct irq_desc *desc, int node)
+void x86_copy_chip_data(struct irq_desc *old_desc,
+ struct irq_desc *desc, int node)
{
struct irq_cfg *cfg;
struct irq_cfg *old_cfg;
@@ -312,7 +312,7 @@ static void free_irq_cfg(struct irq_cfg *old_cfg)
kfree(old_cfg);
}
-void arch_free_chip_data(struct irq_desc *old_desc, struct irq_desc *desc)
+void x86_free_chip_data(struct irq_desc *old_desc, struct irq_desc *desc)
{
struct irq_cfg *old_cfg, *cfg;
@@ -336,6 +336,11 @@ struct irq_cfg *irq_cfg(unsigned int irq)
return irq < nr_irqs ? irq_cfgx + irq : NULL;
}
+int x86_init_chip_data(struct irq_desc *desc, int node)
+{
+ return 0;
+}
+
#endif
struct io_apic {
@@ -1515,7 +1520,7 @@ static void __init setup_IO_APIC_irqs(void)
apic->multi_timer_check(apic_id, irq))
continue;
- desc = irq_to_desc_alloc_node(irq, node);
+ desc = irq_to_desc_alloc_node(irq, node, x86_init_chip_data);
if (!desc) {
printk(KERN_INFO "can not get irq_desc for %d\n", irq);
continue;
@@ -1565,7 +1570,7 @@ void setup_IO_APIC_irq_extra(u32 gsi)
if (desc)
return;
#endif
- desc = irq_to_desc_alloc_node(irq, node);
+ desc = irq_to_desc_alloc_node(irq, node, x86_init_chip_data);
if (!desc) {
printk(KERN_INFO "can not get irq_desc for %d\n", irq);
return;
@@ -2739,6 +2744,11 @@ static struct irq_chip ioapic_chip __read_mostly = {
.set_affinity = set_ioapic_affinity_irq,
#endif
.retrigger = ioapic_retrigger_irq,
+
+#ifdef CONFIG_SPARSE_IRQ
+ .copy_chip_data = x86_copy_chip_data,
+ .free_chip_data = x86_free_chip_data,
+#endif
};
static struct irq_chip ir_ioapic_chip __read_mostly = {
@@ -2754,6 +2764,11 @@ static struct irq_chip ir_ioapic_chip __read_mostly = {
#endif
#endif
.retrigger = ioapic_retrigger_irq,
+
+#ifdef CONFIG_SPARSE_IRQ
+ .copy_chip_data = x86_copy_chip_data,
+ .free_chip_data = x86_free_chip_data,
+#endif
};
static inline void init_IO_APIC_traps(void)
@@ -3256,7 +3271,8 @@ unsigned int create_irq_nr(unsigned int irq_want, int node)
raw_spin_lock_irqsave(&vector_lock, flags);
for (new = irq_want; new < nr_irqs; new++) {
- desc_new = irq_to_desc_alloc_node(new, node);
+ desc_new = irq_to_desc_alloc_node(new, node,
+ x86_init_chip_data);
if (!desc_new) {
printk(KERN_INFO "can not get irq_desc for %d\n", new);
continue;
@@ -3466,6 +3482,11 @@ static struct irq_chip msi_chip = {
.set_affinity = set_msi_irq_affinity,
#endif
.retrigger = ioapic_retrigger_irq,
+
+#ifdef CONFIG_SPARSE_IRQ
+ .copy_chip_data = x86_copy_chip_data,
+ .free_chip_data = x86_free_chip_data,
+#endif
};
static struct irq_chip msi_ir_chip = {
@@ -3479,6 +3500,11 @@ static struct irq_chip msi_ir_chip = {
#endif
#endif
.retrigger = ioapic_retrigger_irq,
+
+#ifdef CONFIG_SPARSE_IRQ
+ .copy_chip_data = x86_copy_chip_data,
+ .free_chip_data = x86_free_chip_data,
+#endif
};
/*
@@ -3638,6 +3664,11 @@ static struct irq_chip dmar_msi_type = {
.set_affinity = dmar_msi_set_affinity,
#endif
.retrigger = ioapic_retrigger_irq,
+
+#ifdef CONFIG_SPARSE_IRQ
+ .copy_chip_data = x86_copy_chip_data,
+ .free_chip_data = x86_free_chip_data,
+#endif
};
int arch_setup_dmar_msi(unsigned int irq)
@@ -3695,6 +3726,11 @@ static struct irq_chip ir_hpet_msi_type = {
#endif
#endif
.retrigger = ioapic_retrigger_irq,
+
+#ifdef CONFIG_SPARSE_IRQ
+ .copy_chip_data = x86_copy_chip_data,
+ .free_chip_data = x86_free_chip_data,
+#endif
};
static struct irq_chip hpet_msi_type = {
@@ -3706,6 +3742,11 @@ static struct irq_chip hpet_msi_type = {
.set_affinity = hpet_msi_set_affinity,
#endif
.retrigger = ioapic_retrigger_irq,
+
+#ifdef CONFIG_SPARSE_IRQ
+ .copy_chip_data = x86_copy_chip_data,
+ .free_chip_data = x86_free_chip_data,
+#endif
};
int arch_setup_hpet_msi(unsigned int irq, unsigned int id)
@@ -3792,6 +3833,11 @@ static struct irq_chip ht_irq_chip = {
.set_affinity = set_ht_irq_affinity,
#endif
.retrigger = ioapic_retrigger_irq,
+
+#ifdef CONFIG_SPARSE_IRQ
+ .copy_chip_data = x86_copy_chip_data,
+ .free_chip_data = x86_free_chip_data,
+#endif
};
int arch_setup_ht_irq(unsigned int irq, struct pci_dev *dev)
@@ -3914,7 +3960,7 @@ static int __io_apic_set_pci_routing(struct device *dev, int irq,
else
node = cpu_to_node(boot_cpu_id);
- desc = irq_to_desc_alloc_node(irq, node);
+ desc = irq_to_desc_alloc_node(irq, node, x86_init_chip_data);
if (!desc) {
printk(KERN_INFO "can not get irq_desc %d\n", irq);
return 0;
@@ -4312,7 +4358,7 @@ void __init pre_init_apic_IRQ0(void)
#ifndef CONFIG_SMP
phys_cpu_present_map = physid_mask_of_physid(boot_cpu_physical_apicid);
#endif
- desc = irq_to_desc_alloc_node(0, 0);
+ desc = irq_to_desc_alloc_node(0, 0, x86_init_chip_data);
setup_local_APIC();
diff --git a/arch/x86/kernel/uv_irq.c b/arch/x86/kernel/uv_irq.c
index ece73d8..df2c6d6 100644
--- a/arch/x86/kernel/uv_irq.c
+++ b/arch/x86/kernel/uv_irq.c
@@ -55,6 +55,11 @@ struct irq_chip uv_irq_chip = {
.eoi = uv_ack_apic,
.end = uv_noop,
.set_affinity = uv_set_irq_affinity,
+
+#ifdef CONFIG_SPARSE_IRQ
+ .copy_chip_data = x86_copy_chip_data,
+ .free_chip_data = x86_free_chip_data,
+#endif
};
/*
diff --git a/arch/x86/lguest/boot.c b/arch/x86/lguest/boot.c
index 7e59dc1..659241a 100644
--- a/arch/x86/lguest/boot.c
+++ b/arch/x86/lguest/boot.c
@@ -841,7 +841,7 @@ static void __init lguest_init_IRQ(void)
*/
void lguest_setup_irq(unsigned int irq)
{
- irq_to_desc_alloc_node(irq, 0);
+ irq_to_desc_alloc_node(irq, 0, NULL);
set_irq_chip_and_handler_name(irq, &lguest_irq_controller,
handle_level_irq, "level");
}
diff --git a/drivers/sh/intc.c b/drivers/sh/intc.c
index 3a5a17d..99f89dd 100644
--- a/drivers/sh/intc.c
+++ b/drivers/sh/intc.c
@@ -870,7 +870,7 @@ void __init register_intc_controller(struct intc_desc *desc)
if (!vect->enum_id)
continue;
- irq_desc = irq_to_desc_alloc_node(irq, numa_node_id());
+ irq_desc = irq_to_desc_alloc_node(irq, numa_node_id(), NULL);
if (unlikely(!irq_desc)) {
pr_info("can't get irq_desc for %d\n", irq);
continue;
@@ -890,7 +890,8 @@ void __init register_intc_controller(struct intc_desc *desc)
* IRQ support, each vector still needs to have
* its own backing irq_desc.
*/
- irq_desc = irq_to_desc_alloc_node(irq2, numa_node_id());
+ irq_desc = irq_to_desc_alloc_node(irq2, numa_node_id(),
+ NULL);
if (unlikely(!irq_desc)) {
pr_info("can't get irq_desc for %d\n", irq2);
continue;
@@ -1012,7 +1013,7 @@ unsigned int create_irq_nr(unsigned int irq_want, int node)
__set_bit(new, intc_irq_map);
}
- desc = irq_to_desc_alloc_node(new, node);
+ desc = irq_to_desc_alloc_node(new, node, NULL);
if (unlikely(!desc)) {
pr_info("can't get irq_desc for %d\n", new);
goto out_unlock;
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 2f84137..0d4f0d3 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -341,7 +341,7 @@ static int find_unbound_irq(void)
if (irq == nr_irqs)
panic("No available IRQ to bind to: increase nr_irqs!\n");
- desc = irq_to_desc_alloc_node(irq, 0);
+ desc = irq_to_desc_alloc_node(irq, 0, NULL);
if (WARN_ON(desc == NULL))
return -1;
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 75f3f00..cc4cd22 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -611,6 +611,6 @@ struct irq_desc;
extern int early_irq_init(void);
extern int arch_probe_nr_irqs(void);
extern int arch_early_irq_init(void);
-extern int arch_init_chip_data(struct irq_desc *desc, int node);
+extern int arch_init_irq_desc(struct irq_desc *desc, int node);
#endif
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 707ab12..e262ca0 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -131,6 +131,14 @@ struct irq_chip {
void (*bus_lock)(unsigned int irq);
void (*bus_sync_unlock)(unsigned int irq);
+ /* for move_irq_desc */
+#ifdef CONFIG_SPARSE_IRQ
+ void (*copy_chip_data)(struct irq_desc *old_desc,
+ struct irq_desc *desc, int node);
+ void (*free_chip_data)(struct irq_desc *old_desc,
+ struct irq_desc *desc);
+#endif
+
/* Currently used only by UML, might disappear one day.*/
#ifdef CONFIG_IRQ_RELEASE_METHOD
void (*release)(unsigned int irq, void *dev_id);
@@ -208,10 +216,6 @@ struct irq_desc {
const char *name;
} ____cacheline_internodealigned_in_smp;
-extern void arch_init_copy_chip_data(struct irq_desc *old_desc,
- struct irq_desc *desc, int node);
-extern void arch_free_chip_data(struct irq_desc *old_desc, struct irq_desc *desc);
-
#ifndef CONFIG_SPARSE_IRQ
extern struct irq_desc irq_desc[NR_IRQS];
#endif
@@ -225,7 +229,9 @@ static inline struct irq_desc *move_irq_desc(struct irq_desc *desc, int node)
}
#endif
-extern struct irq_desc *irq_to_desc_alloc_node(unsigned int irq, int node);
+typedef int (*init_chip_data_fn)(struct irq_desc *, int node);
+extern struct irq_desc *irq_to_desc_alloc_node(unsigned int irq, int node,
+ init_chip_data_fn fn);
/*
* Pick up the arch-dependent methods:
diff --git a/kernel/irq/handle.c b/kernel/irq/handle.c
index 76d5a67..eb060e1 100644
--- a/kernel/irq/handle.c
+++ b/kernel/irq/handle.c
@@ -100,7 +100,8 @@ void __ref init_kstat_irqs(struct irq_desc *desc, int node, int nr)
}
}
-static void init_one_irq_desc(int irq, struct irq_desc *desc, int node)
+static void init_one_irq_desc(int irq, struct irq_desc *desc, int node,
+ init_chip_data_fn init_chip_data)
{
memcpy(desc, &irq_desc_init, sizeof(struct irq_desc));
@@ -120,7 +121,9 @@ static void init_one_irq_desc(int irq, struct irq_desc *desc, int node)
BUG_ON(1);
}
init_desc_masks(desc);
- arch_init_chip_data(desc, node);
+ arch_init_irq_desc(desc, node);
+ if (init_chip_data)
+ init_chip_data(desc, node);
}
/*
@@ -198,7 +201,8 @@ int __init early_irq_init(void)
return arch_early_irq_init();
}
-struct irq_desc * __ref irq_to_desc_alloc_node(unsigned int irq, int node)
+struct irq_desc * __ref irq_to_desc_alloc_node(unsigned int irq, int node,
+ init_chip_data_fn init_chip_data)
{
struct irq_desc *desc;
unsigned long flags;
@@ -227,7 +231,7 @@ struct irq_desc * __ref irq_to_desc_alloc_node(unsigned int irq, int node)
printk(KERN_ERR "can not alloc irq_desc\n");
BUG_ON(1);
}
- init_one_irq_desc(irq, desc, node);
+ init_one_irq_desc(irq, desc, node, init_chip_data);
set_irq_desc(irq, desc);
@@ -277,7 +281,8 @@ struct irq_desc *irq_to_desc(unsigned int irq)
return (irq < NR_IRQS) ? irq_desc + irq : NULL;
}
-struct irq_desc *irq_to_desc_alloc_node(unsigned int irq, int node)
+struct irq_desc *irq_to_desc_alloc_node(unsigned int irq, int node,
+ init_chip_data_fn init_chip_data)
{
return irq_to_desc(irq);
}
diff --git a/kernel/irq/numa_migrate.c b/kernel/irq/numa_migrate.c
index 963559d..9ea09c9 100644
--- a/kernel/irq/numa_migrate.c
+++ b/kernel/irq/numa_migrate.c
@@ -47,7 +47,8 @@ static bool init_copy_one_irq_desc(int irq, struct irq_desc *old_desc,
lockdep_set_class(&desc->lock, &irq_desc_lock_class);
init_copy_kstat_irqs(old_desc, desc, node, nr_cpu_ids);
init_copy_desc_masks(old_desc, desc);
- arch_init_copy_chip_data(old_desc, desc, node);
+ if (desc->chip->copy_chip_data)
+ desc->chip->copy_chip_data(old_desc, desc, node);
return true;
}
@@ -55,7 +56,8 @@ static void free_one_irq_desc(struct irq_desc *old_desc, struct irq_desc *desc)
{
free_kstat_irqs(old_desc, desc);
free_desc_masks(old_desc, desc);
- arch_free_chip_data(old_desc, desc);
+ if (desc->chip->free_chip_data)
+ desc->chip->free_chip_data(old_desc, desc);
}
static struct irq_desc *__real_move_irq_desc(struct irq_desc *old_desc,
@@ -107,9 +109,15 @@ out_unlock:
struct irq_desc *move_irq_desc(struct irq_desc *desc, int node)
{
+
/* those static or target node is -1, do not move them */
if (desc->irq < NR_IRQS_LEGACY || node == -1)
return desc;
+ /* IRQ chip does not support movement */
+ if (desc->chip_data &&
+ (desc->chip->copy_chip_data == NULL ||
+ desc->chip->free_chip_data == NULL))
+ return desc;
if (desc->node != node)
desc = __real_move_irq_desc(desc, node);
diff --git a/kernel/softirq.c b/kernel/softirq.c
index 7c1a67e..3f4b80e 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -895,8 +895,7 @@ int __init __weak arch_early_irq_init(void)
{
return 0;
}
-
-int __weak arch_init_chip_data(struct irq_desc *desc, int node)
+int __weak arch_init_irq_desc(struct irq_desc *desc, int node)
{
return 0;
}
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] powerpc/fsl: Add multiple MSI bank support
From: Kumar Gala @ 2010-03-19 15:15 UTC (permalink / raw)
To: michael; +Cc: Lan Chunhe-B25806, linuxppc-dev
In-Reply-To: <1268968014.30747.136.camel@concordia>
On Mar 18, 2010, at 10:06 PM, Michael Ellerman wrote:
> On Thu, 2010-03-18 at 09:53 -0500, Kumar Gala wrote:
>> From: Lan Chunhe-B25806 <B25806@freescale.com>
>>=20
>> Freescale QorIQ P4080 has three MSI banks and the original code
>> can not work well. This patch adds multiple MSI banks support for
>> Freescale processor.
>>=20
>> Signed-off-by: Lan Chunhe-B25806 <b25806@freescale.com>
>> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
>=20
>> @@ -146,9 +149,13 @@ static int fsl_setup_msi_irqs(struct pci_dev =
*pdev, int nvec, int type)
>> unsigned int virq;
>> struct msi_desc *entry;
>> struct msi_msg msg;
>> - struct fsl_msi *msi_data =3D fsl_msi;
>> + struct fsl_msi *msi_data;
>>=20
>> list_for_each_entry(entry, &pdev->msi_list, list) {
>> + if (entry->irq =3D=3D NO_IRQ)
>> + continue;
>=20
> This looks wrong, entry->irq should always be 0 here because it was =
just
> kzalloc'ed - you should only be doing this check in teardown.
>=20
>> - WARN_ON(ppc_md.setup_msi_irqs);
>> - ppc_md.setup_msi_irqs =3D fsl_setup_msi_irqs;
>> - ppc_md.teardown_msi_irqs =3D fsl_teardown_msi_irqs;
>> - ppc_md.msi_check_device =3D fsl_msi_check_device;
>> + /* The multiple setting ppc_md.setup_msi_irqs will not harm =
things */
>> + if (!ppc_md.setup_msi_irqs) {
>> + ppc_md.setup_msi_irqs =3D fsl_setup_msi_irqs;
>> + ppc_md.teardown_msi_irqs =3D fsl_teardown_msi_irqs;
>> + ppc_md.msi_check_device =3D fsl_msi_check_device;
>> + } else if (ppc_md.setup_msi_irqs !=3D fsl_setup_msi_irqs) {
>> + dev_err(&dev->dev, "Different MSI driver already =
installed!\n");
>> + err =3D -EBUSY; /* or some other error code */
>> + goto error_out;
>> + }
>=20
> I liked it the way it was, because having two competing MSI backends
> means something's probably not going to work. But it's your driver so
> whatever you like.
The previous WARN_ON() is problematic when we have multiple (of the same =
type) MSI blocks. The check was intended to do exactly what you are =
suggesting. If you think its doing something else let us know.
- k=
^ permalink raw reply
* [PATCH 4/7] hvc_console: Fix race between hvc_close and hvc_remove
From: Greg Kroah-Hartman @ 2010-03-19 15:18 UTC (permalink / raw)
To: linux-kernel
Cc: Amit Shah, linuxppc-dev, Rusty Russell, Greg Kroah-Hartman,
Alan Cox
In-Reply-To: <20100319151326.GC8541@kroah.com>
From: Amit Shah <amit.shah@redhat.com>
Alan pointed out a race in the code where hvc_remove is invoked. The
recent virtio_console work is the first user of hvc_remove().
Alan describes it thus:
The hvc_console assumes that a close and remove call can't occur at the
same time.
In addition tty_hangup(tty) is problematic as tty_hangup is asynchronous
itself....
So this can happen
hvc_close hvc_remove
hung up ? - no
lock
tty = hp->tty
unlock
lock
hp->tty = NULL
unlock
notify del
kref_put the hvc struct
close completes
tty is destroyed
tty_hangup dead tty
tty->ops will be NULL
NULL->...
This patch adds some tty krefs and also converts to using tty_vhangup().
Reported-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Amit Shah <amit.shah@redhat.com>
CC: Alan Cox <alan@lxorguk.ukuu.org.uk>
CC: linuxppc-dev@ozlabs.org
CC: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/char/hvc_console.c | 31 +++++++++++++++++++++----------
1 files changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/char/hvc_console.c b/drivers/char/hvc_console.c
index 465185f..ba55bba 100644
--- a/drivers/char/hvc_console.c
+++ b/drivers/char/hvc_console.c
@@ -312,6 +312,7 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
spin_lock_irqsave(&hp->lock, flags);
/* Check and then increment for fast path open. */
if (hp->count++ > 0) {
+ tty_kref_get(tty);
spin_unlock_irqrestore(&hp->lock, flags);
hvc_kick();
return 0;
@@ -319,7 +320,7 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
tty->driver_data = hp;
- hp->tty = tty;
+ hp->tty = tty_kref_get(tty);
spin_unlock_irqrestore(&hp->lock, flags);
@@ -336,6 +337,7 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
spin_lock_irqsave(&hp->lock, flags);
hp->tty = NULL;
spin_unlock_irqrestore(&hp->lock, flags);
+ tty_kref_put(tty);
tty->driver_data = NULL;
kref_put(&hp->kref, destroy_hvc_struct);
printk(KERN_ERR "hvc_open: request_irq failed with rc %d.\n", rc);
@@ -363,13 +365,18 @@ static void hvc_close(struct tty_struct *tty, struct file * filp)
return;
hp = tty->driver_data;
+
spin_lock_irqsave(&hp->lock, flags);
+ tty_kref_get(tty);
if (--hp->count == 0) {
/* We are done with the tty pointer now. */
hp->tty = NULL;
spin_unlock_irqrestore(&hp->lock, flags);
+ /* Put the ref obtained in hvc_open() */
+ tty_kref_put(tty);
+
if (hp->ops->notifier_del)
hp->ops->notifier_del(hp, hp->data);
@@ -389,6 +396,7 @@ static void hvc_close(struct tty_struct *tty, struct file * filp)
spin_unlock_irqrestore(&hp->lock, flags);
}
+ tty_kref_put(tty);
kref_put(&hp->kref, destroy_hvc_struct);
}
@@ -424,10 +432,11 @@ static void hvc_hangup(struct tty_struct *tty)
spin_unlock_irqrestore(&hp->lock, flags);
if (hp->ops->notifier_hangup)
- hp->ops->notifier_hangup(hp, hp->data);
+ hp->ops->notifier_hangup(hp, hp->data);
while(temp_open_count) {
--temp_open_count;
+ tty_kref_put(tty);
kref_put(&hp->kref, destroy_hvc_struct);
}
}
@@ -592,7 +601,7 @@ int hvc_poll(struct hvc_struct *hp)
}
/* No tty attached, just skip */
- tty = hp->tty;
+ tty = tty_kref_get(hp->tty);
if (tty == NULL)
goto bail;
@@ -672,6 +681,8 @@ int hvc_poll(struct hvc_struct *hp)
tty_flip_buffer_push(tty);
}
+ if (tty)
+ tty_kref_put(tty);
return poll_mask;
}
@@ -807,7 +818,7 @@ int hvc_remove(struct hvc_struct *hp)
struct tty_struct *tty;
spin_lock_irqsave(&hp->lock, flags);
- tty = hp->tty;
+ tty = tty_kref_get(hp->tty);
if (hp->index < MAX_NR_HVC_CONSOLES)
vtermnos[hp->index] = -1;
@@ -819,18 +830,18 @@ int hvc_remove(struct hvc_struct *hp)
/*
* We 'put' the instance that was grabbed when the kref instance
* was initialized using kref_init(). Let the last holder of this
- * kref cause it to be removed, which will probably be the tty_hangup
+ * kref cause it to be removed, which will probably be the tty_vhangup
* below.
*/
kref_put(&hp->kref, destroy_hvc_struct);
/*
- * This function call will auto chain call hvc_hangup. The tty should
- * always be valid at this time unless a simultaneous tty close already
- * cleaned up the hvc_struct.
+ * This function call will auto chain call hvc_hangup.
*/
- if (tty)
- tty_hangup(tty);
+ if (tty) {
+ tty_vhangup(tty);
+ tty_kref_put(tty);
+ }
return 0;
}
EXPORT_SYMBOL_GPL(hvc_remove);
--
1.7.0.2
^ permalink raw reply related
* [PATCH] [RFC] Xilinx Virtex 4 FX Soft FPU support
From: Sergey Temerkhanov @ 2010-03-19 15:47 UTC (permalink / raw)
To: linuxppc-dev
This patch enables support for Xilinx Virtex 4 FX singe-float FPU.
Caveats:
- Hard-float binaries which rely on in-kernel math emulation will give wrong
results since they expect 64-bit double-precision instead of 32-bit single-
precision numbers.
Regards, Sergey Temerkhanov
^ 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