[PATCH 07/20] irq: move some interrupt arch_* functions into struct irq_chip.
From: Ian Campbell
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.
-v4: yinghai add irq_to_desc_alloc_node_x...
so could leave default path not changed...
Signed-off-by: Ian Campbell
Acked-by: Michael Ellerman [PowerPC rename portion]
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: H. Peter Anvin
Cc: Eric W. Biederman
Cc: Yinghai Lu
Cc: Jeremy Fitzhardinge
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: x...@kernel.org
Cc: linuxppc-...@ozlabs.org
Cc: linux-ker...@vger.kernel.org
Cc: Rusty Russell
Cc: lgu...@ozlabs.org
Cc: Paul Mundt
Cc: linux...@vger.kernel.org
---
arch/powerpc/kernel/irq.c |2 +-
arch/x86/include/asm/hw_irq.h |7 +-
arch/x86/kernel/apic/io_apic.c | 49 ---
arch/x86/kernel/uv_irq.c |3 ++
drivers/xen/events.c |7 +-
include/linux/interrupt.h |1 -
include/linux/irq.h| 21 +
kernel/irq/chip.c |7 +
kernel/irq/handle.c| 13 ++
kernel/irq/numa_migrate.c | 12 -
kernel/softirq.c |5
11 files changed, 102 insertions(+), 25 deletions(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 64f6f20..cafd378 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -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, init_chip_data_fn fn)
{
desc->status |= IRQ_NOREQUEST;
return 0;
diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h
index 46c0fe0..767d3f8 100644
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -20,9 +20,9 @@
#include
#include
#include
+#include
#include
-#include
#include
/* Interrupt handlers registered during init_IRQ */
@@ -61,6 +61,11 @@ extern void init_VISWS_APIC_irqs(void);
extern void setup_IO_APIC(void);
extern void disable_IO_APIC(void);
+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);
+
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 463de9a..a917fdf 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)
+static 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;
@@ -329,6 +329,14 @@ void arch_free_chip_data(struct irq_desc *old_desc, struct
irq_desc *desc)
}
}
/* end for move_irq_desc */
+int arch_init_irq_desc(struct irq_desc *desc, int node,
+init_chip_data_fn init_chip_da
Re: [PATCH] Macintosh: fix brace and trailing statement coding style issues in adb-iop.c This is a patch to the adb-iop.c file that cleans up brace and trailing statement warnings found by the checkpa
> On Tue, Mar 09, 2010 at 01:46:20PM -0800, Michael Beardsworth wrote:
> >...
> >
> > #ifdef DEBUG_ADB_IOP
> > - printk("adb_iop_listen %p: rcvd packet, %d bytes: %02X %02X", req,
> > - (uint) amsg->count + 2, (uint) amsg->flags, (uint) amsg->cmd);
> > + printk(KERN_WARNING "adb_iop_listen %p: rcvd packet, %d bytes: %02X
> > %02X",
> > + req, (uint) amsg->count + 2, (uint) amsg->flags, (uint)
> > amsg->cmd);
> > for (i = 0; i < amsg->count; i++)
> > printk(" %02X", (uint) amsg->data[i]);
> > printk("\n");
> >...
> > #ifdef DEBUG_ADB_IOP
> > - printk("adb_iop_start %p: sending packet, %d bytes:", req, req->nbytes);
> > + printk(KERN_WARNING "adb_iop_start %p: sending packet, %d bytes:", req,
> > req->nbytes);
> > for (i = 0 ; i < req->nbytes ; i++)
> > printk(" %02X", (uint) req->data[i]);
> > printk("\n");
KERN_DEBUG is used for debugging messages, not KERN_WARNING.
Finn
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Macintosh: fix brace and trailing statement coding style issues in adb-iop.c This is a patch to the adb-iop.c file that cleans up brace and trailing statement warnings found by the check
On Sun, Mar 21, 2010 at 10:16, wrote:
>> On Tue, Mar 09, 2010 at 01:46:20PM -0800, Michael Beardsworth wrote:
>> >...
>> >
>> > #ifdef DEBUG_ADB_IOP
>> > - printk("adb_iop_listen %p: rcvd packet, %d bytes: %02X %02X", req,
>> > - (uint) amsg->count + 2, (uint) amsg->flags, (uint) amsg->cmd);
>> > + printk(KERN_WARNING "adb_iop_listen %p: rcvd packet, %d bytes: %02X
>> > %02X",
>> > + req, (uint) amsg->count + 2, (uint) amsg->flags, (uint)
>> > amsg->cmd);
>> > for (i = 0; i < amsg->count; i++)
>> > printk(" %02X", (uint) amsg->data[i]);
>> > printk("\n");
>
>> >...
>> > #ifdef DEBUG_ADB_IOP
>> > - printk("adb_iop_start %p: sending packet, %d bytes:", req,
>> > req->nbytes);
>> > + printk(KERN_WARNING "adb_iop_start %p: sending packet, %d bytes:",
>> > req, req->nbytes);
>> > for (i = 0 ; i < req->nbytes ; i++)
>> > printk(" %02X", (uint) req->data[i]);
>> > printk("\n");
>
> KERN_DEBUG is used for debugging messages, not KERN_WARNING.
And that change is not covered by the patch description.
BTW, pr_debug(), these days.
> int adb_iop_init(void)
> {
> - printk("adb: IOP ISM driver v0.4 for Unified ADB.\n");
> + printk(KERN_MESSAGE "adb: IOP ISM driver v0.4 for Unified ADB.\n");
>iop_listen(ADB_IOP, ADB_CHAN, adb_iop_listen, "ADB");
> return 0;
> }
Not to mention the non-existence of KERN_MESSAGE?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/4] panic: Allow taint flag for warnings to be changed from TAINT_WARN
On Sun, 2010-03-21 at 20:10 +0100, Andi Kleen wrote: > Ben Hutchings writes: > > > WARN() is used in some places to report firmware or hardware bugs that > > are then worked-around. These bugs do not affect the stability of the > > kernel and should not set the usual TAINT_WARN flag. To allow for > > this, add WARN_TAINT() and WARN_TAINT_ONCE() macros that take a taint > > flag as argument. > > > > Architectures that implement warnings using trap instructions instead > > of calls to warn_slowpath_*() must now implement __WARN_TAINT(taint) > > instead of __WARN(). > > I guess this should enforce that at least some taint flag is set? > (e.g. with a BUILD_BUG_ON) I'm being a bit sloppy with the wording here. The TAINT_* macros are actually bit numbers, not flags. I could define a TAINT_MAX and add: BUILD_BUG_ON(taint < 0 || taint > TAINT_MAX); Not sure that that's really worth doing though. Ben. -- Ben Hutchings If you seem to know what you are doing, you'll be given more to do. signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/4] panic: Allow taint flag for warnings to be changed from TAINT_WARN
Ben Hutchings writes: > WARN() is used in some places to report firmware or hardware bugs that > are then worked-around. These bugs do not affect the stability of the > kernel and should not set the usual TAINT_WARN flag. To allow for > this, add WARN_TAINT() and WARN_TAINT_ONCE() macros that take a taint > flag as argument. > > Architectures that implement warnings using trap instructions instead > of calls to warn_slowpath_*() must now implement __WARN_TAINT(taint) > instead of __WARN(). I guess this should enforce that at least some taint flag is set? (e.g. with a BUILD_BUG_ON) -Andi -- a...@linux.intel.com -- Speaking for myself only. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/fsl: Add multiple MSI bank support
On Fri, 2010-03-19 at 10:15 -0500, Kumar Gala wrote:
> 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
> >>
> >> 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
> >> Signed-off-by: Roy Zang
> >
> >> @@ -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.
This was the important comment, the rest was nit-picking :)
> >> - 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.
>
> 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.
Right, yeah I see what you mean - dev_err() is a bit harder to spot than
a WARN() but it's probably sufficient.
cheers
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
could you help me the GPIO problem on MPC8323?
hi,all: i saw peter's mpc8xxx_gpio.c in kernel 2.6.31. it seems that file can only be used on 831x and others, but not mpc8323. my platform is mpc8323, how can i use the GPIO? i also found "QE GPIO Support" and "Support for simple, memory-mapped GPIO controllers" selection, would that be helpful for me? how can i use? thanks, best regards. evan. ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 01/10] irq: move some interrupt arch_* functions into struct irq_chip.
From: Ian Campbell
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.
-v4: yinghai add irq_to_desc_alloc_node_x...
so could leave default path not changed...
Signed-off-by: Ian Campbell
Acked-by: Michael Ellerman [PowerPC rename portion]
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: H. Peter Anvin
Cc: Eric W. Biederman
Cc: Yinghai Lu
Cc: Jeremy Fitzhardinge
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: x...@kernel.org
Cc: linuxppc-...@ozlabs.org
Cc: linux-ker...@vger.kernel.org
Cc: Rusty Russell
Cc: lgu...@ozlabs.org
Cc: Paul Mundt
Cc: linux...@vger.kernel.org
---
arch/powerpc/kernel/irq.c |2 +-
arch/x86/include/asm/hw_irq.h |7 +-
arch/x86/kernel/apic/io_apic.c | 49 ---
arch/x86/kernel/uv_irq.c |3 ++
drivers/xen/events.c |7 +-
include/linux/interrupt.h |1 -
include/linux/irq.h| 21 +
kernel/irq/chip.c |7 +
kernel/irq/handle.c| 13 ++
kernel/irq/numa_migrate.c | 12 -
kernel/softirq.c |5
11 files changed, 102 insertions(+), 25 deletions(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 64f6f20..cafd378 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -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, init_chip_data_fn fn)
{
desc->status |= IRQ_NOREQUEST;
return 0;
diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h
index 46c0fe0..767d3f8 100644
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -20,9 +20,9 @@
#include
#include
#include
+#include
#include
-#include
#include
/* Interrupt handlers registered during init_IRQ */
@@ -61,6 +61,11 @@ extern void init_VISWS_APIC_irqs(void);
extern void setup_IO_APIC(void);
extern void disable_IO_APIC(void);
+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);
+
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 463de9a..a917fdf 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)
+static 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;
@@ -329,6 +329,14 @@ void arch_free_chip_data(struct irq_desc *old_desc, struct
irq_desc *desc)
}
}
/* end for move_irq_desc */
+int arch_init_irq_desc(struct irq_desc *desc, int node,
+init_chip_data_fn init_chip_da
Re: [PATCH 01/10] irq: move some interrupt arch_* functions into struct irq_chip.
On Sun, 2010-03-21 at 18:36 -0700, Yinghai Lu wrote:
> From: Ian Campbell
...
> 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.
...
>
> -v4: yinghai add irq_to_desc_alloc_node_x...
> so could leave default path not changed...
Apologies for not noticing this sooner, but ..
> --- a/arch/powerpc/kernel/irq.c
> +++ b/arch/powerpc/kernel/irq.c
> @@ -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, init_chip_data_fn fn)
> {
> desc->status |= IRQ_NOREQUEST;
> return 0;
This is a bit feral, that is the init_chip_data_fn.
It seems like it only exists to support the following on x86:
> +int arch_init_irq_desc(struct irq_desc *desc, int node,
> + init_chip_data_fn init_chip_data)
> +{
> + if (!init_chip_data)
> + return x86_init_chip_data(desc, node);
> +
> + return init_chip_data(desc, node);
> +}
Which is really just a hack to avoid an if (xen) check isn't it?
It looks to me like this should just be done via a current machine
vector or platform routine, in the same way as powerpc and (I think)
ia64, ie:
> +int arch_init_irq_desc(struct irq_desc *desc, int node)
> +{
> + return current_machine->init_chip_data(desc, node);
> +}
cheers
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/fsl: Add multiple MSI bank support
On Thu, Mar 18, 2010 at 9:53 AM, Kumar Gala wrote:
> + /* 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 */
The comment is inappropriate. I put it there as a reminder that maybe
EBUSY is not the best choice. But if it is, then the comment should
be removed.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 01/10] irq: move some interrupt arch_* functions into struct irq_chip.
On 03/21/2010 06:56 PM, Michael Ellerman wrote:
> On Sun, 2010-03-21 at 18:36 -0700, Yinghai Lu wrote:
>> From: Ian Campbell
> ...
>> 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.
> ...
>>
>> -v4: yinghai add irq_to_desc_alloc_node_x...
>> so could leave default path not changed...
>
> Apologies for not noticing this sooner, but ..
>
>> --- a/arch/powerpc/kernel/irq.c
>> +++ b/arch/powerpc/kernel/irq.c
>> @@ -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, init_chip_data_fn
>> fn)
>> {
>> desc->status |= IRQ_NOREQUEST;
>> return 0;
>
> This is a bit feral, that is the init_chip_data_fn.
>
> It seems like it only exists to support the following on x86:
>
>> +int arch_init_irq_desc(struct irq_desc *desc, int node,
>> + init_chip_data_fn init_chip_data)
>> +{
>> +if (!init_chip_data)
>> +return x86_init_chip_data(desc, node);
>> +
>> +return init_chip_data(desc, node);
>> +}
>
> Which is really just a hack to avoid an if (xen) check isn't it?
arch/powerpc/kernel/irq.c |2 +-
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 64f6f20..cafd378 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -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, init_chip_data_fn fn)
{
desc->status |= IRQ_NOREQUEST;
return 0;
so this patch only change one line with powerpc code.
>
> It looks to me like this should just be done via a current machine
> vector or platform routine, in the same way as powerpc and (I think)
> ia64, ie:
>
>> +int arch_init_irq_desc(struct irq_desc *desc, int node)
>> +{
>> +return current_machine->init_chip_data(desc, node);
>> +}
>
looks like xen in same run time, some irqs need x86_init_chip_data,
and some may need xen_init_chip_data later.
Thanks
Yinghai
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] device_attributes: add sysfs_attr_init() for dynamic attributes
Made necessary by 6992f5334995af474c2b58d010d08bc597f0f2fe.
Found by this semantic patch:
@ init @
type T;
identifier A;
@@
T {
...
struct device_attribute A;
...
};
@ main extends init @
expression E;
statement S;
identifier err;
T *name;
@@
... when != sysfs_attr_init(&name->A.attr);
(
+ sysfs_attr_init(&name->A.attr);
if (device_create_file(E, &name->A))
S
|
+ sysfs_attr_init(&name->A.attr);
err = device_create_file(E, &name->A);
)
While reviewing, I put the initialization to apropriate places.
Signed-off-by: Wolfram Sang
Cc: Eric W. Biederman
Cc: Greg KH
Cc: Benjamin Herrenschmidt
Cc: Mike Isely
Cc: Mauro Carvalho Chehab
Cc: Sujith Thomas
Cc: Matthew Garrett
---
The thermal-sys.c-part should fix bugs #15548 and #15584.
drivers/macintosh/windfarm_core.c |1 +
drivers/media/video/pvrusb2/pvrusb2-sysfs.c |8
drivers/platform/x86/intel_menlow.c |1 +
drivers/thermal/thermal_sys.c |1 +
drivers/video/fsl-diu-fb.c |1 +
5 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/macintosh/windfarm_core.c
b/drivers/macintosh/windfarm_core.c
index 419795f..f447642 100644
--- a/drivers/macintosh/windfarm_core.c
+++ b/drivers/macintosh/windfarm_core.c
@@ -209,6 +209,7 @@ int wf_register_control(struct wf_control *new_ct)
kref_init(&new_ct->ref);
list_add(&new_ct->link, &wf_controls);
+ sysfs_attr_init(&new_ct->attr.attr);
new_ct->attr.attr.name = new_ct->name;
new_ct->attr.attr.mode = 0644;
new_ct->attr.show = wf_show_control;
diff --git a/drivers/media/video/pvrusb2/pvrusb2-sysfs.c
b/drivers/media/video/pvrusb2/pvrusb2-sysfs.c
index 6c23456..71f5056 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-sysfs.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-sysfs.c
@@ -423,10 +423,12 @@ static void pvr2_sysfs_add_debugifc(struct pvr2_sysfs
*sfp)
dip = kzalloc(sizeof(*dip),GFP_KERNEL);
if (!dip) return;
+ sysfs_attr_init(&dip->attr_debugcmd.attr);
dip->attr_debugcmd.attr.name = "debugcmd";
dip->attr_debugcmd.attr.mode = S_IRUGO|S_IWUSR|S_IWGRP;
dip->attr_debugcmd.show = debugcmd_show;
dip->attr_debugcmd.store = debugcmd_store;
+ sysfs_attr_init(&dip->attr_debuginfo.attr);
dip->attr_debuginfo.attr.name = "debuginfo";
dip->attr_debuginfo.attr.mode = S_IRUGO;
dip->attr_debuginfo.show = debuginfo_show;
@@ -644,6 +646,7 @@ static void class_dev_create(struct pvr2_sysfs *sfp,
return;
}
+ sysfs_attr_init(&sfp->attr_v4l_minor_number.attr);
sfp->attr_v4l_minor_number.attr.name = "v4l_minor_number";
sfp->attr_v4l_minor_number.attr.mode = S_IRUGO;
sfp->attr_v4l_minor_number.show = v4l_minor_number_show;
@@ -658,6 +661,7 @@ static void class_dev_create(struct pvr2_sysfs *sfp,
sfp->v4l_minor_number_created_ok = !0;
}
+ sysfs_attr_init(&sfp->attr_v4l_radio_minor_number.attr);
sfp->attr_v4l_radio_minor_number.attr.name = "v4l_radio_minor_number";
sfp->attr_v4l_radio_minor_number.attr.mode = S_IRUGO;
sfp->attr_v4l_radio_minor_number.show = v4l_radio_minor_number_show;
@@ -672,6 +676,7 @@ static void class_dev_create(struct pvr2_sysfs *sfp,
sfp->v4l_radio_minor_number_created_ok = !0;
}
+ sysfs_attr_init(&sfp->attr_unit_number.attr);
sfp->attr_unit_number.attr.name = "unit_number";
sfp->attr_unit_number.attr.mode = S_IRUGO;
sfp->attr_unit_number.show = unit_number_show;
@@ -685,6 +690,7 @@ static void class_dev_create(struct pvr2_sysfs *sfp,
sfp->unit_number_created_ok = !0;
}
+ sysfs_attr_init(&sfp->attr_bus_info.attr);
sfp->attr_bus_info.attr.name = "bus_info_str";
sfp->attr_bus_info.attr.mode = S_IRUGO;
sfp->attr_bus_info.show = bus_info_show;
@@ -699,6 +705,7 @@ static void class_dev_create(struct pvr2_sysfs *sfp,
sfp->bus_info_created_ok = !0;
}
+ sysfs_attr_init(&sfp->attr_hdw_name.attr);
sfp->attr_hdw_name.attr.name = "device_hardware_type";
sfp->attr_hdw_name.attr.mode = S_IRUGO;
sfp->attr_hdw_name.show = hdw_name_show;
@@ -713,6 +720,7 @@ static void class_dev_create(struct pvr2_sysfs *sfp,
sfp->hdw_name_created_ok = !0;
}
+ sysfs_attr_init(&sfp->attr_hdw_desc.attr);
sfp->attr_hdw_desc.attr.name = "device_hardware_description";
sfp->attr_hdw_desc.attr.mode = S_IRUGO;
sfp->attr_hdw_desc.show = hdw_desc_show;
diff --git a/drivers/platform/x86/intel_menlow.c
b/drivers/platform/x86/intel_menlow.c
index f0a90a6..90ba5d7 100644
--- a/drivers/platform/x86/intel_menlow.c
+++ b/drivers/platform/x86/intel_menlow.c
@@ -396,6 +396,7 @@ static int intel_menlo
Re: Freescale MPC5554 device tree (was: cross-compiling Linux for PowerPC e200 core?)
Hi Grant,
thanks for the comments, I solved some of the points you mentioned. I need some
more time to work on the others. In the meantime I send the intermediate
version.
Grant Likely wrote:
> 2010/3/13 Németh Márton :
[...]
>> + mem...@4000 {
>> + device_type = "memory";
>> + reg = <0x4000 0x1>; // 32KiB internal SRAM
>> + };
>
> Oh this is the small SRAM. yeah, you should move this under the
> appropriate bridge node, remove the device_type property, and add a
> compatible property. Memory nodes at the root like this are used to
> describe what is basically main memory (what Linux will execute out
> of). You'll want a new memory node for the external ram hooked up to
> the 5554.
Yes, it is the small one (actually 64KiB, I corrected the comment also).
I added the external memory of the MPC5554DEMO evaluation board which has
a size of 512KiB.
Would it be possible to program the uncompressed kernel to the FLASH so
it can run directly from there? I guess for the code and the constant sections
the FLASH could be a good place. Then cstart has to initialize the initialized
variables by copying data from FLASH to RAM and fill the BSS area with zero.
[...]
>> + s...@3f89000 { // System Integration Unit
>> + compatible = "fsl,mpc5554-siu";
>> + reg = <0x03f9 0x4000>;
>> + interrupts = <45 1 // External
>> Interrupt Overrun 0-15
>> + 46 1 // External
>> Interrupt 0
>> + 47 1 // External
>> Interrupt 1
>> + 48 1 // External
>> Interrupt 2
>> + 49 1 // External
>> Interrupt 3
>> + 50 1>;// External
>> Interrupt 4-15
>> + };
>
> This doesn't look quite right /me goes to look at the 5554
> reference manual
>
> Okay, so all the external IRQs go through the SIU then, even though
> the first 4 get passed straight through to the intc? And I see that
> all the level/edge sensing and masking/acknowledging is done at the
> SIU level, not the intc level, correct? So, what you effectively have
> is the SIU is *another* interrupt controller that is cascaded to the
> intc. Therefore you need to add the following to this node:
>
> #interrupt-cells = <2>; // cell1:extirq#, cell2:level/edge flags
> interrupt-controller;
>
> Also give the node a label so that nodes for external devices can
> reference it for hooking up external irqs by overriding the top-level
> interrupt-parent property.
>
> Also, it would appear that intc interrupts don't have any level/edge
> configuration associated with them. They are either asserted, or they
> are not, correct? At the moment you're specifying every intc
> interrupt with 2 cells, and the 2nd cell is always '1'. I think you
> can change #interrupt-cells to <1> in the intc node and drop the '1'
> everywhere.
>
> When you write your intc driver, you'll also need to write the
> cascaded driver for the external IRQs.
I tried to solve this point but I'm not quite sure whether the SIU interrupt
numbers shall be kept on the s...@3f89000 node or not.
>> + em...@3fa { // Modular Timer System
>> + compatible = "fsl,mpc5554-emios";
>> + reg = <0x03fa 0x4000>;
>> + interrupts = <51 1 // Channel 0
>> + 52 1 // Channel 1
>> + 53 1 // Channel 2
>> + 54 1 // Channel 3
>> + 55 1 // Channel 4
>> + 56 1 // Channel 5
>> + 57 1 // Channel 6
>> + 58 1 // Channel 7
>> + 59 1 // Channel 8
>> + 60 1 // Channel 9
>> + 61 1 // Channel 10
>> + 62 1 // Channel 11
>> + 63 1 // Channel 12
>> + 64 1 // Channel 13
>> + 65 1 // Channel 14
>> + 66 1 // Channel 15
>> + 202 1 // Channel 16
>> + 203 1 // Channel 17
>> + 204 1 // Channel 18
>> +
Re: [PATCH] device_attributes: add sysfs_attr_init() for dynamic attributes
Hi Wolfram,
On Mon, Mar 22, 2010 at 07:21:17AM +0100, Wolfram Sang wrote:
> Made necessary by 6992f5334995af474c2b58d010d08bc597f0f2fe.
>
> Found by this semantic patch:
>
> @ init @
> type T;
> identifier A;
> @@
>
> T {
> ...
> struct device_attribute A;
> ...
> };
>
> @ main extends init @
> expression E;
> statement S;
> identifier err;
> T *name;
> @@
>
> ... when != sysfs_attr_init(&name->A.attr);
> (
> + sysfs_attr_init(&name->A.attr);
> if (device_create_file(E, &name->A))
> S
> |
> + sysfs_attr_init(&name->A.attr);
> err = device_create_file(E, &name->A);
> )
>
> While reviewing, I put the initialization to apropriate places.
>
My standard question - are all of these need to be dynamically
allocated?
Thanks.
--
Dmitry
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
ppc64 sys_ipc breakage in 2.6.34-rc2
I chased down a fail on ppc64 on 2.6.34-rc2 where an application that uses
shared memory was getting a SEGV.
Commit baed7fc9b580bd3fb8252ff1d9b36eaf1f86b670 (Add generic sys_ipc wrapper)
changed the second argument from an unsigned long to an int. When we call
shmget the system call wrappers for sys_ipc will sign extend second (ie the
size) which truncates it. It took a while to track down because the call
succeeds and strace shows the untruncated size :)
The patch below changes second from an int to an unsigned long which fixes
shmget on ppc64 (and I assume s390, sparc64 and mips64).
Signed-off-by: Anton Blanchard
--
I assume the function prototypes for the other IPC methods would cause us
to sign or zero extend second where appropriate (avoiding any security
issues). Come to think of it, the syscall wrappers for each method should do
that for us as well.
diff --git a/ipc/syscall.c b/ipc/syscall.c
index 355a3da..1d6f53f 100644
--- a/ipc/syscall.c
+++ b/ipc/syscall.c
@@ -13,7 +13,7 @@
#include
#include
-SYSCALL_DEFINE6(ipc, unsigned int, call, int, first, int, second,
+SYSCALL_DEFINE6(ipc, unsigned int, call, int, first, unsigned long, second,
unsigned long, third, void __user *, ptr, long, fifth)
{
int version, ret;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
