* madness, was Re: [PATCH 2/2] Macintosh: fix coding style issues in adb.c This is a patch to the adb.c file that cleans up many warnings found by the checkpatch.pl tool
From: fthain @ 2010-03-10 3:48 UTC (permalink / raw)
To: Michael Beardsworth
Cc: monstr, linux-kernel, linuxppc-dev, geert, Nick Savage
In-Reply-To: <1268172438-76422-1-git-send-email-mbeards2@uoregon.edu>
On Tue, 9 Mar 2010, Michael Beardsworth wrote:
> - /* If a probe is in progress or we are sleeping, wait for it to complete */
> + /* If a probe is in progress or we are sleeping, wait until complete */
If you must "fix" what aint broke, please try not to damage it. I'm sorry
if your VT52 is limited to 80 cols, but IMNSHO this sort of effort is
misguided.
Maybe I could point out again (I do this periodically) that checkpatch.pl
is great but code that fails it is NOT always wrong.
"Check patch" is a good idea but "check existing code" is a waste of
everyone's time.
Finn
^ permalink raw reply
* Re: [RFC] powerpc: add support for new hcall H_BEST_ENERGY
From: Vaidyanathan Srinivasan @ 2010-03-10 4:30 UTC (permalink / raw)
To: Dipankar Sarma; +Cc: Paul Mackerras, Anton Blanchard, linuxppc-dev
In-Reply-To: <20100308192826.GJ10402@in.ibm.com>
* Dipankar Sarma <dipankar@in.ibm.com> [2010-03-09 00:58:26]:
> On Mon, Mar 08, 2010 at 12:20:06PM +0530, Vaidyanathan Srinivasan wrote:
> > * Dipankar Sarma <dipankar@in.ibm.com> [2010-03-06 00:48:11]:
> >
> > > Shouldn't we create this only for supported platforms ?
> >
> > Hi Dipankar,
> >
> > Yes we will need a check like
> > firmware_has_feature(FW_FEATURE_BEST_ENERGY) to avoid sysfs files in
> > unsupported platforms. I will add that check in the next iteration.
>
> Also, given that this module isn't likely to provide anything on
> older platforms, it should get loaded only on newer platforms.
Yes, I will explore methods to achieve this. I could not yet find
a trigger to load modules based on firmware feature.
--Vaidy
^ permalink raw reply
* 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 checkpatch.pl tool. Signed-off-by: Michael Beardsworth <m
From: Grant Likely @ 2010-03-10 4:46 UTC (permalink / raw)
To: Michael Beardsworth; +Cc: linuxppc-dev, benh, Michael Beardsworth, linux-kernel
Hi Michael,
Thanks for the patch. However, whitespace changes like this usually
aren't worth bothering with. Yeah, sure, they are technically
violations to the coding style, but they aren't egregious and aren't a
serious impediment to readability. In general I don't want to see
purely minor coding style cleanup patches unless they are part of a
larger effort to tighten up and fix bugs in a driver. Otherwise it is
just churn for little or no return on effort.
A good place to go looking for really bad code that needs cleaning
effort is in the staging/ directory.
Cheers,
g.
On Tue, Mar 9, 2010 at 2:46 PM, Michael Beardsworth
<mbeards2@uoregon.edu> wrote:
> From: Michael Beardsworth <mbeards@mbeards-mbp.lulzzzzzzz.info>
>
> ---
> =A0drivers/macintosh/adb-iop.c | =A0 41 +++++++++++++++++++++++----------=
--------
> =A01 files changed, 23 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/macintosh/adb-iop.c b/drivers/macintosh/adb-iop.c
> index 4446966..e813589 100644
> --- a/drivers/macintosh/adb-iop.c
> +++ b/drivers/macintosh/adb-iop.c
> @@ -19,13 +19,13 @@
> =A0#include <linux/init.h>
> =A0#include <linux/proc_fs.h>
>
> -#include <asm/macintosh.h>
> -#include <asm/macints.h>
> +#include <asm/macintosh.h>
> +#include <asm/macints.h>
> =A0#include <asm/mac_iop.h>
> =A0#include <asm/mac_oss.h>
> =A0#include <asm/adb_iop.h>
>
> -#include <linux/adb.h>
> +#include <linux/adb.h>
>
> =A0/*#define DEBUG_ADB_IOP*/
>
> @@ -67,7 +67,8 @@ static void adb_iop_end_req(struct adb_request *req, in=
t state)
> =A0{
> =A0 =A0 =A0 =A0req->complete =3D 1;
> =A0 =A0 =A0 =A0current_req =3D req->next;
> - =A0 =A0 =A0 if (req->done) (*req->done)(req);
> + =A0 =A0 =A0 if (req->done)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 (*req->done)(req);
> =A0 =A0 =A0 =A0adb_iop_state =3D state;
> =A0}
>
> @@ -85,9 +86,8 @@ static void adb_iop_complete(struct iop_msg *msg)
> =A0 =A0 =A0 =A0local_irq_save(flags);
>
> =A0 =A0 =A0 =A0req =3D current_req;
> - =A0 =A0 =A0 if ((adb_iop_state =3D=3D sending) && req && req->reply_exp=
ected) {
> + =A0 =A0 =A0 if ((adb_iop_state =3D=3D sending) && req && req->reply_exp=
ected)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0adb_iop_state =3D awaiting_reply;
> - =A0 =A0 =A0 }
>
> =A0 =A0 =A0 =A0local_irq_restore(flags);
> =A0}
> @@ -113,8 +113,8 @@ static void adb_iop_listen(struct iop_msg *msg)
> =A0 =A0 =A0 =A0req =3D current_req;
>
> =A0#ifdef DEBUG_ADB_IOP
> - =A0 =A0 =A0 printk("adb_iop_listen %p: rcvd packet, %d bytes: %02X %02X=
", req,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 (uint) amsg->count + 2, (uint) amsg->flags,=
(uint) amsg->cmd);
> + =A0 =A0 =A0 printk(KERN_WARNING "adb_iop_listen %p: rcvd packet, %d byt=
es: %02X %02X",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 req, (uint) amsg->count + 2, (uint) amsg->f=
lags, (uint) amsg->cmd);
> =A0 =A0 =A0 =A0for (i =3D 0; i < amsg->count; i++)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printk(" %02X", (uint) amsg->data[i]);
> =A0 =A0 =A0 =A0printk("\n");
> @@ -130,9 +130,8 @@ static void adb_iop_listen(struct iop_msg *msg)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0msg->reply[0] =3D ADB_IOP_TIMEOUT | ADB_IO=
P_AUTOPOLL;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0msg->reply[1] =3D 0;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0msg->reply[2] =3D 0;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (req && (adb_iop_state !=3D idle)) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (req && (adb_iop_state !=3D idle))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0adb_iop_end_req(req, idle)=
;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0} else {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* TODO: is it possible for more than one =
chunk of data =A0*/
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* =A0 =A0 =A0 to arrive before the timeou=
t? If so we need to */
> @@ -169,12 +168,13 @@ static void adb_iop_start(void)
>
> =A0 =A0 =A0 =A0/* get the packet to send */
> =A0 =A0 =A0 =A0req =3D current_req;
> - =A0 =A0 =A0 if (!req) return;
> + =A0 =A0 =A0 if (!req)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return;
>
> =A0 =A0 =A0 =A0local_irq_save(flags);
>
> =A0#ifdef DEBUG_ADB_IOP
> - =A0 =A0 =A0 printk("adb_iop_start %p: sending packet, %d bytes:", req, =
req->nbytes);
> + =A0 =A0 =A0 printk(KERN_WARNING "adb_iop_start %p: sending packet, %d b=
ytes:", req, req->nbytes);
> =A0 =A0 =A0 =A0for (i =3D 0 ; i < req->nbytes ; i++)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printk(" %02X", (uint) req->data[i]);
> =A0 =A0 =A0 =A0printk("\n");
> @@ -203,13 +203,14 @@ static void adb_iop_start(void)
>
> =A0int adb_iop_probe(void)
> =A0{
> - =A0 =A0 =A0 if (!iop_ism_present) return -ENODEV;
> + =A0 =A0 =A0 if (!iop_ism_present)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENODEV;
> =A0 =A0 =A0 =A0return 0;
> =A0}
>
> =A0int adb_iop_init(void)
> =A0{
> - =A0 =A0 =A0 printk("adb: IOP ISM driver v0.4 for Unified ADB.\n");
> + =A0 =A0 =A0 printk(KERN_MESSAGE "adb: IOP ISM driver v0.4 for Unified A=
DB.\n");
> =A0 =A0 =A0 =A0iop_listen(ADB_IOP, ADB_CHAN, adb_iop_listen, "ADB");
> =A0 =A0 =A0 =A0return 0;
> =A0}
> @@ -219,10 +220,12 @@ int adb_iop_send_request(struct adb_request *req, i=
nt sync)
> =A0 =A0 =A0 =A0int err;
>
> =A0 =A0 =A0 =A0err =3D adb_iop_write(req);
> - =A0 =A0 =A0 if (err) return err;
> + =A0 =A0 =A0 if (err)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return err;
>
> =A0 =A0 =A0 =A0if (sync) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 while (!req->complete) adb_iop_poll();
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 while (!req->complete)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 adb_iop_poll();
> =A0 =A0 =A0 =A0}
> =A0 =A0 =A0 =A0return 0;
> =A0}
> @@ -252,7 +255,8 @@ static int adb_iop_write(struct adb_request *req)
> =A0 =A0 =A0 =A0}
>
> =A0 =A0 =A0 =A0local_irq_restore(flags);
> - =A0 =A0 =A0 if (adb_iop_state =3D=3D idle) adb_iop_start();
> + =A0 =A0 =A0 if (adb_iop_state =3D=3D idle)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 adb_iop_start();
> =A0 =A0 =A0 =A0return 0;
> =A0}
>
> @@ -264,7 +268,8 @@ int adb_iop_autopoll(int devs)
>
> =A0void adb_iop_poll(void)
> =A0{
> - =A0 =A0 =A0 if (adb_iop_state =3D=3D idle) adb_iop_start();
> + =A0 =A0 =A0 if (adb_iop_state =3D=3D idle)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 adb_iop_start();
> =A0 =A0 =A0 =A0iop_ism_irq(0, (void *) ADB_IOP);
> =A0}
>
> --
> 1.6.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" i=
n
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at =A0http://www.tux.org/lkml/
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] irq: move some interrupt arch_* functions into struct irq_chip.
From: ijc @ 2010-03-10 10:55 UTC (permalink / raw)
To: linux-kernel
Cc: Jeremy Fitzhardinge, Ian Campbell, x86, linuxppc-dev, Ingo Molnar,
Paul Mackerras, Eric W. Biederman, H. Peter Anvin,
Thomas Gleixner, Yinghai Lu
In-Reply-To: <1268218524.11737.68547.camel@zakaz.uk.xensource.com>
From: Ian Campbell <ian.campbell@citrix.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 at this time
because irq_desc->chip is not known at the time the irq_desc is
setup. For now rename arch_init_chip_data to arch_init_irq_desc (for
PowerPC, the only other user, whose usage better matches the new name)
and on x86 convert arch_init_chip_data to ioapic_init_chip_data and
call this whenever the IO APIC code allocates a new IRQ.
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
ioapic_{init,copy,free}_chip_data functions could be static to
io_apic.c.
I've tested by booting on a 64 bit system, 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>
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
---
arch/powerpc/kernel/irq.c | 2 +-
arch/x86/include/asm/hw_irq.h | 11 +++++++-
arch/x86/kernel/apic/io_apic.c | 58 +++++++++++++++++++++++++++++++++++++---
arch/x86/kernel/uv_irq.c | 5 +++
include/linux/interrupt.h | 2 +-
include/linux/irq.h | 12 +++++---
kernel/irq/handle.c | 2 +-
kernel/irq/numa_migrate.c | 12 +++++++-
kernel/softirq.c | 3 +-
9 files changed, 91 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 64f6f20..002d87f 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)
{
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 0642186..b9d7310 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 ioapic_init_chip_data(struct irq_desc *desc, int node);
+
+#ifdef CONFIG_SPARSE_IRQ
+extern void ioapic_copy_chip_data(struct irq_desc *old_desc,
+ struct irq_desc *desc, int node);
+extern void ioapic_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 a57d974..74d5d96 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -211,7 +211,7 @@ static struct ioapic_irq_cfg *get_one_free_irq_cfg(int node)
return cfg;
}
-int arch_init_chip_data(struct irq_desc *desc, int node)
+int ioapic_init_chip_data(struct irq_desc *desc, int node)
{
struct ioapic_irq_cfg *cfg;
@@ -289,8 +289,8 @@ static void free_irq_2_pin(struct ioapic_irq_cfg *old_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 ioapic_copy_chip_data(struct irq_desc *old_desc,
+ struct irq_desc *desc, int node)
{
struct ioapic_irq_cfg *cfg;
struct ioapic_irq_cfg *old_cfg;
@@ -314,7 +314,7 @@ static void free_irq_cfg(struct ioapic_irq_cfg *old_cfg)
kfree(old_cfg);
}
-void arch_free_chip_data(struct irq_desc *old_desc, struct irq_desc *desc)
+void ioapic_free_chip_data(struct irq_desc *old_desc, struct irq_desc *desc)
{
struct ioapic_irq_cfg *old_cfg, *cfg;
@@ -338,6 +338,11 @@ struct ioapic_irq_cfg *ioapic_irq_cfg(unsigned int irq)
return irq < nr_irqs ? irq_cfgx + irq : NULL;
}
+int ioapic_init_chip_data(struct irq_desc *desc, int node)
+{
+ return 0;
+}
+
#endif
struct io_apic {
@@ -1526,6 +1531,7 @@ static void __init setup_IO_APIC_irqs(void)
printk(KERN_INFO "can not get irq_desc for %d\n", irq);
continue;
}
+ ioapic_init_chip_data(desc, node);
cfg = desc->chip_data;
add_pin_to_irq_node(cfg, node, apic_id, pin);
/*
@@ -1576,6 +1582,7 @@ void setup_IO_APIC_irq_extra(u32 gsi)
printk(KERN_INFO "can not get irq_desc for %d\n", irq);
return;
}
+ ioapic_init_chip_data(desc, node);
cfg = desc->chip_data;
add_pin_to_irq_node(cfg, node, apic_id, pin);
@@ -2746,6 +2753,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 = ioapic_copy_chip_data,
+ .free_chip_data = ioapic_free_chip_data,
+#endif
};
static struct irq_chip ir_ioapic_chip __read_mostly = {
@@ -2761,6 +2773,11 @@ static struct irq_chip ir_ioapic_chip __read_mostly = {
#endif
#endif
.retrigger = ioapic_retrigger_irq,
+
+#ifdef CONFIG_SPARSE_IRQ
+ .copy_chip_data = ioapic_copy_chip_data,
+ .free_chip_data = ioapic_free_chip_data,
+#endif
};
static inline void init_IO_APIC_traps(void)
@@ -3268,6 +3285,7 @@ unsigned int create_irq_nr(unsigned int irq_want, int node)
printk(KERN_INFO "can not get irq_desc for %d\n", new);
continue;
}
+ ioapic_init_chip_data(desc_new, node);
cfg_new = desc_new->chip_data;
if (cfg_new->vector != 0)
@@ -3474,6 +3492,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 = ioapic_copy_chip_data,
+ .free_chip_data = ioapic_free_chip_data,
+#endif
};
static struct irq_chip msi_ir_chip = {
@@ -3487,6 +3510,11 @@ static struct irq_chip msi_ir_chip = {
#endif
#endif
.retrigger = ioapic_retrigger_irq,
+
+#ifdef CONFIG_SPARSE_IRQ
+ .copy_chip_data = ioapic_copy_chip_data,
+ .free_chip_data = ioapic_free_chip_data,
+#endif
};
/*
@@ -3646,6 +3674,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 = ioapic_copy_chip_data,
+ .free_chip_data = ioapic_free_chip_data,
+#endif
};
int arch_setup_dmar_msi(unsigned int irq)
@@ -3703,6 +3736,11 @@ static struct irq_chip ir_hpet_msi_type = {
#endif
#endif
.retrigger = ioapic_retrigger_irq,
+
+#ifdef CONFIG_SPARSE_IRQ
+ .copy_chip_data = ioapic_copy_chip_data,
+ .free_chip_data = ioapic_free_chip_data,
+#endif
};
static struct irq_chip hpet_msi_type = {
@@ -3714,6 +3752,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 = ioapic_copy_chip_data,
+ .free_chip_data = ioapic_free_chip_data,
+#endif
};
int arch_setup_hpet_msi(unsigned int irq, unsigned int id)
@@ -3800,6 +3843,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 = ioapic_copy_chip_data,
+ .free_chip_data = ioapic_free_chip_data,
+#endif
};
int arch_setup_ht_irq(unsigned int irq, struct pci_dev *dev)
@@ -3927,6 +3975,7 @@ static int __io_apic_set_pci_routing(struct device *dev, int irq,
printk(KERN_INFO "can not get irq_desc %d\n", irq);
return 0;
}
+ ioapic_init_chip_data(desc, node);
pin = irq_attr->ioapic_pin;
trigger = irq_attr->trigger;
@@ -4321,6 +4370,7 @@ void __init pre_init_apic_IRQ0(void)
phys_cpu_present_map = physid_mask_of_physid(boot_cpu_physical_apicid);
#endif
desc = irq_to_desc_alloc_node(0, 0);
+ ioapic_init_chip_data(desc, 0);
setup_local_APIC();
diff --git a/arch/x86/kernel/uv_irq.c b/arch/x86/kernel/uv_irq.c
index 3520564..96020cb 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 = ioapic_copy_chip_data,
+ .free_chip_data = ioapic_free_chip_data,
+#endif
};
/*
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..558bd2d 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
diff --git a/kernel/irq/handle.c b/kernel/irq/handle.c
index 76d5a67..168e2f8 100644
--- a/kernel/irq/handle.c
+++ b/kernel/irq/handle.c
@@ -120,7 +120,6 @@ 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);
}
/*
@@ -228,6 +227,7 @@ struct irq_desc * __ref irq_to_desc_alloc_node(unsigned int irq, int node)
BUG_ON(1);
}
init_one_irq_desc(irq, desc, node);
+ arch_init_irq_desc(desc, node);
set_irq_desc(irq, desc);
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] irq: move some interrupt arch_* functions into struct irq_chip.
From: Ian Campbell @ 2010-03-10 11:00 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org
Cc: Jeremy Fitzhardinge, x86@kernel.org, linuxppc-dev@ozlabs.org,
Ingo Molnar, Paul Mackerras, Eric W. Biederman, H. Peter Anvin,
Thomas Gleixner, Yinghai Lu
In-Reply-To: <1268218559-26784-2-git-send-email-ijc@hellion.org.uk>
On Wed, 2010-03-10 at 10:55 +0000, ijc@hellion.org.uk wrote:
>
> arch_init_chip_data cannot be moved into struct irq_chip at this time
> because irq_desc->chip is not known at the time the irq_desc is
> setup. For now rename arch_init_chip_data to arch_init_irq_desc (for
> PowerPC, the only other user, whose usage better matches the new name)
> and on x86 convert arch_init_chip_data to ioapic_init_chip_data and
> call this whenever the IO APIC code allocates a new IRQ.
One idea I had to improve this was to add a struct irq_chip * as a
parameter to irq_to_desc_alloc_node. The new parameter potentially could
be NULL for current behaviour. Does that sound like a reasonable
approach?
Ian.
^ permalink raw reply
* Re: [PATCH] irq: move some interrupt arch_* functions into struct irq_chip.
From: Yinghai Lu @ 2010-03-10 12:06 UTC (permalink / raw)
To: ijc
Cc: Jeremy Fitzhardinge, Ian Campbell, x86, linux-kernel,
linuxppc-dev, Ingo Molnar, Paul Mackerras, Eric W. Biederman,
H. Peter Anvin, Thomas Gleixner
In-Reply-To: <1268218559-26784-2-git-send-email-ijc@hellion.org.uk>
On Wed, Mar 10, 2010 at 2:55 AM, <ijc@hellion.org.uk> wrote:
> From: Ian Campbell <ian.campbell@citrix.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 at this time
> because irq_desc->chip is not known at the time the irq_desc is
> setup. For now rename arch_init_chip_data to arch_init_irq_desc (for
> PowerPC, the only other user, whose usage better matches the new name)
> and on x86 convert arch_init_chip_data to ioapic_init_chip_data and
> call this whenever the IO APIC code allocates a new IRQ.
>
> 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
> ioapic_{init,copy,free}_chip_data functions could be static to
> io_apic.c.
>
> I've tested by booting on a 64 bit system, but it's not clear to me
> what actions I need to take to actually exercise some of these code
> paths.
>
can you just add another pointer field in irq_desc?
some kind of *irq_info etc.
YH
^ permalink raw reply
* [PATCH v2] powerpc: export data from new hcall H_EM_GET_PARMS
From: Vaidyanathan Srinivasan @ 2010-03-10 12:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Anton Blanchard; +Cc: linuxppc-dev
Hi Ben,
I have cleaned up the code from the previous post:
http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-February/080630.html
Changes from v1:
* Removed redundant return statements and rearranged code
Description:
A new hcall H_EM_GET_PARMS as been added to obtain power mode data
from the platform. This data can be used by user space administrative
tools for better power management.
The following patch add data from this new hcall into the lparcfg
driver and exports to user space along with other existing lpar data
in /proc/powerpc/lparcfg
Please review and include in powerpc -next tree.
Thanks,
Vaidy
---
powerpc: export data from new hcall H_EM_GET_PARMS
Add support for H_EM_GET_PARMS hcall that will return data
related to power modes from the platform. Export the data
directly to user space for administrative tools to interpret
and use.
cat /proc/powerpc/lparcfg will export power mode data
Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/hvcall.h | 1 +
arch/powerpc/kernel/lparcfg.c | 12 +++++++++++-
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/hvcall.h b/arch/powerpc/include/asm/hvcall.h
index f027581..ebe7493 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -228,6 +228,7 @@
#define H_JOIN 0x298
#define H_VASI_STATE 0x2A4
#define H_ENABLE_CRQ 0x2B0
+#define H_GET_EM_PARMS 0x2B8
#define H_SET_MPP 0x2D0
#define H_GET_MPP 0x2D4
#define MAX_HCALL_OPCODE H_GET_MPP
diff --git a/arch/powerpc/kernel/lparcfg.c b/arch/powerpc/kernel/lparcfg.c
index d09d1c6..ff698fb 100644
--- a/arch/powerpc/kernel/lparcfg.c
+++ b/arch/powerpc/kernel/lparcfg.c
@@ -37,7 +37,7 @@
#include <asm/vio.h>
#include <asm/mmu.h>
-#define MODULE_VERS "1.8"
+#define MODULE_VERS "1.9"
#define MODULE_NAME "lparcfg"
/* #define LPARCFG_DEBUG */
@@ -486,6 +486,14 @@ static void splpar_dispatch_data(struct seq_file *m)
seq_printf(m, "dispatch_dispersions=%lu\n", dispatch_dispersions);
}
+static void parse_em_data(struct seq_file *m)
+{
+ unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
+
+ if (plpar_hcall(H_GET_EM_PARMS, retbuf) == H_SUCCESS)
+ seq_printf(m, "power_mode_data=%016lx\n", retbuf[0]);
+}
+
static int pseries_lparcfg_data(struct seq_file *m, void *v)
{
int partition_potential_processors;
@@ -540,6 +548,8 @@ static int pseries_lparcfg_data(struct seq_file *m, void *v)
seq_printf(m, "slb_size=%d\n", mmu_slb_size);
+ parse_em_data(m);
+
return 0;
}
^ permalink raw reply related
* Re: [PATCH] irq: move some interrupt arch_* functions into struct irq_chip.
From: Ian Campbell @ 2010-03-10 12:51 UTC (permalink / raw)
To: Yinghai Lu
Cc: Jeremy Fitzhardinge, x86@kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@ozlabs.org, Ingo Molnar, Paul Mackerras,
Eric W. Biederman, H. Peter Anvin, Thomas Gleixner
In-Reply-To: <86802c441003100406t70dd854fx491f0ee9a6fce62b@mail.gmail.com>
On Wed, 2010-03-10 at 12:06 +0000, Yinghai Lu wrote:
> On Wed, Mar 10, 2010 at 2:55 AM, <ijc@hellion.org.uk> wrote:
> > From: Ian Campbell <ian.campbell@citrix.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 at this time
> > because irq_desc->chip is not known at the time the irq_desc is
> > setup. For now rename arch_init_chip_data to arch_init_irq_desc (for
> > PowerPC, the only other user, whose usage better matches the new name)
> > and on x86 convert arch_init_chip_data to ioapic_init_chip_data and
> > call this whenever the IO APIC code allocates a new IRQ.
> >
> > 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
> > ioapic_{init,copy,free}_chip_data functions could be static to
> > io_apic.c.
> >
> > I've tested by booting on a 64 bit system, but it's not clear to me
> > what actions I need to take to actually exercise some of these code
> > paths.
> >
>
> can you just add another pointer field in irq_desc?
>
> some kind of *irq_info etc.
I think I don't understand what you are suggesting.
There is already a pointer for irq_chip specific use i.e.
irq_desc->chip_data. This patchset is just about ensuring that the field
really is available to any chip implementation rather than just assuming
it is always used for the acpi chip types (on x86 at least).
Does adding a second pointer with the same (intended?) semantics as the
existing one buy us anything?
Ian.
^ permalink raw reply
* mv643xx_eth broken again on pegasos2 G4
From: acrux @ 2010-03-10 15:14 UTC (permalink / raw)
To: linuxppc-dev
hi,
mv643xx_eth driver seems to be broken (and very often there is a kernel panic too).
Last working kernel is 2.6.31.2
here a dmesg from 2.6.32.9:
memory = 1024MB; using 2048kB for hash table (at cfe00000)
Linux version 2.6.32.9 (root@pegasos2) (gcc version 4.3.4 (CRUX PPC) (GCC) ) #1
PREEMPT Wed Mar 10 15:56:51 CET 2010
Found legacy serial port 0 for /pci@80000000/isa@C/serial@i2F8
port=2f8, taddr=fe0002f8, irq=0, clk=1843200, speed=0
bootconsole [udbg0] enabled
chrp type = 6 [Genesi Pegasos]
Pegasos l2cr : L2 cache was not active, activating
PCI bus 0 controlled by /pci@80000000 at 80000000
PCI host bridge /pci@80000000 (primary) ranges:
IO 0x00000000fe000000..0x00000000fe00ffff -> 0x0000000000000000
MEM 0x0000000080000000..0x00000000bfffffff -> 0x0000000080000000
PCI bus 0 controlled by /pci@C0000000 at c0000000
PCI host bridge /pci@C0000000 ranges:
IO 0x00000000f8000000..0x00000000f800ffff -> 0x0000000000000000
MEM 0x00000000c0000000..0x00000000dfffffff -> 0x00000000c0000000
Top of RAM: 0x40000000, Total RAM: 0x40000000
Memory hole size: 0MB
Zone PFN ranges:
DMA 0x00000000 -> 0x00030000
Normal 0x00030000 -> 0x00030000
HighMem 0x00030000 -> 0x00040000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000000 -> 0x00040000
On node 0 totalpages: 262144
free_area_init_node: node 0, pgdat c045b65c, node_mem_map c0baf000
DMA zone: 1536 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 195072 pages, LIFO batch:31
HighMem zone: 512 pages used for memmap
HighMem zone: 65024 pages, LIFO batch:15
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260096
Kernel command line: root=/dev/hda5 video=radeonfb:800x600@60 mv643xx_eth=no
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
High memory: 262080k
Memory: 1031700k/1048576k available (4268k kernel code, 16184k reserved, 236k da
ta, 120k bss, 160k init)
Kernel virtual memory layout:
* 0xfffef000..0xfffff000 : fixmap
* 0xff800000..0xffc00000 : highmem PTEs
* 0xff7e0000..0xff800000 : early ioremap
* 0xf1000000..0xff7e0000 : vmalloc & ioremap
SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Hierarchical RCU implementation.
NR_IRQS:512
i8259 legacy interrupt controller initialized
time_init: decrementer frequency = 33.333333 MHz
time_init: processor frequency = 999.999990 MHz
clocksource: timebase mult[7800001] shift[22] registered
clockevent: decrementer mult[8888887] shift[32] cpu[0]
Console: colour dummy device 80x25
console [tty0] enabled, bootconsole disabled
Mount-cache hash table entries: 512
NET: Registered protocol family 16
PCI: Probing PCI hardware
pci 0000:00:01.0: reg 10 32bit mmio: [0x80000000-0x800007ff]
pci 0000:00:01.0: reg 14 io port: [0x1080-0x10ff]
pci 0000:00:01.0: supports D2
pci 0000:00:01.0: PME# supported from D2 D3hot D3cold
pci 0000:00:01.0: PME# disabled
pci 0000:00:0c.1: reg 10 io port: [0x1000-0x1007]
pci 0000:00:0c.1: reg 14 io port: [0x100c-0x100f]
pci 0000:00:0c.1: reg 18 io port: [0x1010-0x1017]
pci 0000:00:0c.1: reg 1c io port: [0x101c-0x101f]
pci 0000:00:0c.1: reg 20 io port: [0x1020-0x102f]
pci 0000:00:0c.2: reg 20 io port: [0x1040-0x105f]
pci 0000:00:0c.3: reg 20 io port: [0x1060-0x107f]
pci 0000:00:0c.5: reg 10 io port: [0x1100-0x11ff]
pci 0000:00:0c.5: reg 14 io port: [0x1030-0x1033]
pci 0000:00:0c.5: reg 18 io port: [0x1034-0x1037]
pci 0000:00:0c.6: reg 10 io port: [0x1200-0x12ff]
pci 0000:00:0d.0: reg 10 io port: [0x1300-0x13ff]
pci 0000:00:0d.0: reg 14 32bit mmio: [0x80000800-0x800008ff]
pci 0000:00:0d.0: PME# supported from D0 D3hot D3cold
pci 0000:00:0d.0: PME# disabled
pci 0001:01:08.0: reg 10 32bit mmio pref: [0xc0000000-0xc7ffffff]
pci 0001:01:08.0: reg 14 io port: [0x1000-0x10ff]
pci 0001:01:08.0: reg 18 32bit mmio: [0xc8000000-0xc800ffff]
pci 0001:01:08.0: reg 30 32bit mmio pref: [0xc8020000-0xc803ffff]
pci 0001:01:08.0: supports D1 D2
pci 0001:01:08.1: reg 10 32bit mmio pref: [0xd0000000-0xd7ffffff]
pci 0001:01:08.1: reg 14 32bit mmio: [0xc8010000-0xc801ffff]
pci 0001:01:08.1: supports D1 D2
PCI 0000:00 Cannot reserve Legacy IO [0x00-0xfff]
pci_bus 0000:00: resource 0 io: [0x00-0xffff]
pci_bus 0000:00: resource 1 mem: [0x80000000-0xbfffffff]
pci_bus 0001:01: resource 0 io: [0xffff0000-0xffffffff]
pci_bus 0001:01: resource 1 mem: [0xc0000000-0xdfffffff]
bio: create slab <bio-0> at 0
vgaarb: device added: PCI:0001:01:08.0,decodes=io+mem,owns=io+mem,locks=none
vgaarb: loaded
SCSI subsystem initialized
Switching to clocksource timebase
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
NET: Registered protocol family 1
pci 0000:00:0c.1: Fixing VIA IDE, force legacy mode on
Thermal assist unit not available
highmem bounce pool size: 64 pages
msgmni has been set to 1504
alg: No test for stdrng (krng)
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered
io scheduler cfq registered (default)
radeonfb: Found Intel x86 BIOS ROM Image
radeonfb: No ATY,RefCLK property !
radeonfb: Retrieved PLL infos from BIOS
radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=240.00 Mhz, System=166.00 MHz
radeonfb: PLL min 20000 max 40000
i2c i2c-2: unable to read EDID block.
i2c i2c-2: unable to read EDID block.
i2c i2c-2: unable to read EDID block.
i2c i2c-3: unable to read EDID block.
i2c i2c-3: unable to read EDID block.
i2c i2c-3: unable to read EDID block.
radeonfb: Monitor 1 type CRT found
radeonfb: EDID probed
radeonfb: Monitor 2 type no found
Console: switching to colour frame buffer device 100x37
radeonfb (0001:01:08.0): ATI Radeon 5960 "Y`"
Generic non-volatile memory driver v1.1
Linux agpgart interface v0.103
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
serial8250.0: ttyS0 at I/O 0x2f8 (irq = 0) is a 16550A
brd: module loaded
loop: module loaded
Uniform Multi-Platform E-IDE driver
via82cxxx 0000:00:0c.1: VIA vt8231 (rev 10) IDE UDMA100
via82cxxx 0000:00:0c.1: IDE controller (0x1106:0x0571 rev 0x06)
via82cxxx 0000:00:0c.1: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0x1020-0x1027
ide1: BM-DMA at 0x1028-0x102f
Probing IDE interface ide0...
hda: ST340810A, ATA DISK drive
hda: host max PIO5 wanted PIO255(auto-tune) selected PIO4
hda: UDMA/100 mode selected
Probing IDE interface ide1...
hdc: SAMSUNG CDRW/DVD SM-352B, ATAPI CD/DVD-ROM drive
hdc: host max PIO5 wanted PIO255(auto-tune) selected PIO4
hdc: UDMA/33 mode selected
ide0 at 0x1000-0x1007,0x100e on irq 14
ide1 at 0x1010-0x1017,0x101e on irq 15
ide-gd driver 1.18
hda: max request size: 128KiB
hda: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=65535/16/63
hda: cache flushes not supported
hda: hda1 hda2 hda3 < hda5 hda6 hda7 >
ide-cd driver 5.00
ide-cd: hdc: ATAPI 52X DVD-ROM CD-R/RW drive, 2048kB Cache
Uniform CD-ROM driver Revision: 3.20
Fixed MDIO Bus: probed
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0
i2c /dev entries driver
Linux video capture interface: v2.00
device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: dm-devel@redhat.com
atkbd.c: keyboard reset failed on isa0060/serio0
Advanced Linux Sound Architecture Driver Version 1.0.21.
ALSA device list:
No soundcards found.
TCP cubic registered
NET: Registered protocol family 17
input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input0
REISERFS (device hda5): found reiserfs format "3.6" with standard journal
REISERFS (device hda5): using ordered data mode
REISERFS (device hda5): journal params: device hda5, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
REISERFS (device hda5): checking transaction log (hda5)
REISERFS (device hda5): Using r5 hash to sort names
VFS: Mounted root (reiserfs filesystem) readonly on device 3:5.
Freeing unused kernel memory: 160k init
via-rhine.c:v1.10-LK1.4.3 2007-03-06 Written by Donald Becker
via-rhine 0000:00:0d.0: enabling device (0000 -> 0003)
eth0: VIA Rhine II at 0x80000800, 00:0b:2f:4f:65:7b, IRQ 9.
eth0: MII PHY found at address 16, status 0x786d advertising 01e1 Link 45e1.
MV-643xx 10/100/1000 ethernet driver version 1.4
sysfs: cannot create duplicate filename '/class/mdio_bus/0'
------------[ cut here ]------------
Badness at fs/sysfs/dir.c:491
NIP: c00dc568 LR: c00dc568 CTR: c00200ac
REGS: ef015c70 TRAP: 0700 Not tainted (2.6.32.9)
MSR: 00029032 <EE,ME,CE,IR,DR> CR: 22422488 XER: 00000000
TASK = ef082bc0[1011] 'modprobe' THREAD: ef014000
GPR00: c00dc568 ef015d20 ef082bc0 00000042 c04303f0 c04303f0 00000000 00000001
GPR08: 00000000 00000000 01430ee0 ffffffff 81f2ba43 10020a5c 00000000 00000000
GPR16: 00000000 00000000 100056bc 00000003 4801f000 00000000 00000000 c0430120
GPR24: 107fb560 107fb57c ef17fc48 00000001 ffffffef ef015d48 ef108030 ef355000
NIP [c00dc568] sysfs_add_one+0x7c/0xa0
LR [c00dc568] sysfs_add_one+0x7c/0xa0
Call Trace:
[ef015d20] [c00dc568] sysfs_add_one+0x7c/0xa0 (unreliable)
[ef015d40] [c00dd700] sysfs_do_create_link+0xf4/0x188
[ef015d70] [c022ffbc] device_add+0x1a8/0x51c
[ef015db0] [c026be38] mdiobus_register+0xa0/0x1ac
[ef015de0] [f224d5dc] mv643xx_eth_shared_probe+0x140/0x3f8 [mv643xx_eth]
[ef015e00] [c0233dd0] platform_drv_probe+0x20/0x30
[ef015e10] [c0232a4c] driver_probe_device+0xd4/0x1a8
[ef015e30] [c0232b90] __driver_attach+0x70/0xa4
[ef015e50] [c02320cc] bus_for_each_dev+0x5c/0xac
[ef015e80] [c023285c] driver_attach+0x24/0x34
[ef015e90] [c0231910] bus_add_driver+0xb4/0x248
[ef015eb0] [c0232f78] driver_register+0xd0/0x174
[ef015ed0] [c023412c] platform_driver_register+0x6c/0x7c
[ef015ee0] [f2256024] mv643xx_eth_init_module+0x24/0x80 [mv643xx_eth]
[ef015f00] [c0003ee0] do_one_initcall+0x64/0x1f8
[ef015f20] [c0054680] sys_init_module+0xe0/0x224
[ef015f40] [c0013828] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xff69720
LR = 0x10004150
Instruction dump:
807d0000 7fe4fb78 4bffff51 3c80c03a 3884adb0 4bf3ce4d 809e0010 4bf3ce45
7c641b78 3c60c03b 38639868 48259099 <0fe00000> 7fe3fb78 4bfaac0d 80010024
mii_bus 0 failed to register
mv643xx_eth: probe of mv643xx_eth.0 failed with error -12
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xf2250908
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT CHRP
Modules linked in: mv643xx_eth(+) via_rhine serio_raw parport firewire_core
NIP: f2250908 LR: f2250900 CTR: c0232574
REGS: ef015d10 TRAP: 0300 Tainted: G W (2.6.32.9)
MSR: 00009032 <EE,ME,IR,DR> CR: 84422488 XER: 20000000
DAR: 00000000, DSISR: 40000000
TASK = ef082bc0[1011] 'modprobe' THREAD: ef014000
GPR00: f22508f4 ef015dc0 ef082bc0 00000000 efb42300 efb42005 efb4214d 00000000
GPR08: 00000000 00000001 2bfd0c6b c0232574 00000000 10020a5c 00000000 00000000
GPR16: 00000000 00000000 100056bc 00000003 c0430230 00000000 00000000 00000000
GPR24: c0430228 107fb57c 00000000 efb42000 f22528c0 fffffff4 c04300d8 efb42300
NIP [f2250908] mv643xx_eth_probe+0xac/0x620 [mv643xx_eth]
LR [f2250900] mv643xx_eth_probe+0xa4/0x620 [mv643xx_eth]
Call Trace:
[ef015dc0] [f22508f4] mv643xx_eth_probe+0x98/0x620 [mv643xx_eth] (unreliable)
[ef015e00] [c0233dd0] platform_drv_probe+0x20/0x30
[ef015e10] [c0232a4c] driver_probe_device+0xd4/0x1a8
[ef015e30] [c0232b90] __driver_attach+0x70/0xa4
[ef015e50] [c02320cc] bus_for_each_dev+0x5c/0xac
[ef015e80] [c023285c] driver_attach+0x24/0x34
[ef015e90] [c0231910] bus_add_driver+0xb4/0x248
[ef015eb0] [c0232f78] driver_register+0xd0/0x174
[ef015ed0] [c023412c] platform_driver_register+0x6c/0x7c
[ef015ee0] [f2256034] mv643xx_eth_init_module+0x34/0x80 [mv643xx_eth]
[ef015f00] [c0003ee0] do_one_initcall+0x64/0x1f8
[ef015f20] [c0054680] sys_init_module+0xe0/0x224
[ef015f40] [c0013828] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xff69720
LR = 0x10004150
Instruction dump:
7c7b1b79 41820528 3bfb0300 3a980008 7e83a378 7fe4fb78 48000dd1 807e0000
38630008 480011b5 907b0300 813e0004 <80030000> 5529502a 39290400 7c004a14
---[ end trace 1a9241f24ee15efc ]---
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
uhci_hcd: USB Universal Host Controller Interface driver
uhci_hcd 0000:00:0c.2: enabling device (0000 -> 0001)
uhci_hcd 0000:00:0c.2: UHCI Host Controller
uhci_hcd 0000:00:0c.2: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:0c.2: irq 9, io base 0x00001040
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
uhci_hcd 0000:00:0c.3: enabling device (0000 -> 0001)
uhci_hcd 0000:00:0c.3: UHCI Host Controller
uhci_hcd 0000:00:0c.3: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:0c.3: irq 9, io base 0x00001060
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
vt596_smbus 0000:00:0c.4: SMBUS: Error: Host SMBus controller not enabled! - upgrade BIOS or use force=1
firewire_ohci 0000:00:01.0: enabling device (0000 -> 0003)
parport_pc: VIA 686A/8231 detected
parport_pc: probing current configuration
firewire_ohci: Added fw-ohci device 0000:00:01.0, OHCI version 1.0
parport_pc: Current parallel port base: 0x3BC
parport0: PC-style at 0x3bc, irq 7 [PCSPP]
parport_pc: VIA parallel port: io=0x3BC, irq=7
VIA 82xx Audio 0000:00:0c.5: enabling device (0000 -> 0001)
usb 1-2: new low speed USB device using uhci_hcd and address 2
usb 1-2: configuration #1 chosen from 1 choice
usbcore: registered new interface driver hiddev
input: MOSART Semi. Wireless Keyboard & Mouse as /devices/pci0000:00/0000:00:0c.2/usb1/1-2/1-2:1.0/input/input1
generic-usb 0003:062A:0102.0001: input: USB HID v1.10 Keyboard [MOSART Semi. Wireless Keyboard & Mouse] on usb-0000:00:0c.2-2/input0
usb 2-2: new full speed USB device using uhci_hcd and address 2
input: MOSART Semi. Wireless Keyboard & Mouse as /devices/pci0000:00/0000:00:0c.2/usb1/1-2/1-2:1.1/input/input2
firewire_core: created device fw0: GUID 0011060000004b2f, S400
generic-usb 0003:062A:0102.0002: input,hiddev0: USB HID v1.10 Mouse [MOSART Semi. Wireless Keyboard & Mouse] on usb-0000:00:0c.2-2/input1
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
usb 2-2: configuration #1 chosen from 1 choice
hub 2-2:1.0: USB hub found
hub 2-2:1.0: 4 ports detected
REISERFS (device hda6): found reiserfs format "3.6" with standard journal
REISERFS (device hda6): using ordered data mode
REISERFS (device hda6): journal params: device hda6, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
REISERFS (device hda6): checking transaction log (hda6)
REISERFS (device hda6): Using r5 hash to sort names
REISERFS (device hda7): found reiserfs format "3.6" with standard journal
REISERFS (device hda7): using ordered data mode
REISERFS (device hda7): journal params: device hda7, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
REISERFS (device hda7): checking transaction log (hda7)
REISERFS (device hda7): Using r5 hash to sort names
Adding 499992k swap on /dev/hda1. Priority:-1 extents:1 across:499992k
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
NET: Registered protocol family 10
hda: UDMA/100 mode selected
hda: cache flushes not supported
eth0: no IPv6 routers present
--n
--
acrux <acrux_it@libero.it>
^ permalink raw reply
* Re: mv643xx_eth broken again on pegasos2 G4
From: Gabriel Paubert @ 2010-03-10 16:43 UTC (permalink / raw)
To: acrux; +Cc: linuxppc-dev
In-Reply-To: <20100310161441.6e76143f.acrux_it@libero.it>
On Wed, Mar 10, 2010 at 04:14:41PM +0100, acrux wrote:
> hi,
> mv643xx_eth driver seems to be broken (and very often there is a kernel panic too).
> Last working kernel is 2.6.31.2
>
> here a dmesg from 2.6.32.9:
My Pegasos running a pristine 2.6.32 seems to disagree with you.
[...]
Linux version 2.6.32 (xxx@yyy) (gcc version 4.3.2 (Debian 4.3.2-1.1) ) #129 Mon Jan 18 16:29:40 GMT 2010
Found legacy serial port 0 for /pci@80000000/isa@C/serial@i2F8
port=2f8, taddr=fe0002f8, irq=0, clk=1843200, speed=0
chrp type = 6 [Genesi Pegasos]
[...]
MV-643xx 10/100/1000 ethernet driver version 1.4
mv643xx_eth smi: probed
net eth1: port 1 with MAC address 00:0b:2f:15:10:ef
net eth1: configured with sram
[...]
This said I cannot go close to it right now to compile and test
something newer. But I can connect to it through the network
and it uses the mv643xx_eth port.
The difference may be that mv643xx_eth is built-in and not modular.
> MV-643xx 10/100/1000 ethernet driver version 1.4
> sysfs: cannot create duplicate filename '/class/mdio_bus/0'
> ------------[ cut here ]------------
> Badness at fs/sysfs/dir.c:491
> NIP: c00dc568 LR: c00dc568 CTR: c00200ac
> REGS: ef015c70 TRAP: 0700 Not tainted (2.6.32.9)
> MSR: 00029032 <EE,ME,CE,IR,DR> CR: 22422488 XER: 00000000
> TASK = ef082bc0[1011] 'modprobe' THREAD: ef014000
> GPR00: c00dc568 ef015d20 ef082bc0 00000042 c04303f0 c04303f0 00000000 00000001
> GPR08: 00000000 00000000 01430ee0 ffffffff 81f2ba43 10020a5c 00000000 00000000
> GPR16: 00000000 00000000 100056bc 00000003 4801f000 00000000 00000000 c0430120
> GPR24: 107fb560 107fb57c ef17fc48 00000001 ffffffef ef015d48 ef108030 ef355000
> NIP [c00dc568] sysfs_add_one+0x7c/0xa0
> LR [c00dc568] sysfs_add_one+0x7c/0xa0
> Call Trace:
> [ef015d20] [c00dc568] sysfs_add_one+0x7c/0xa0 (unreliable)
> [ef015d40] [c00dd700] sysfs_do_create_link+0xf4/0x188
> [ef015d70] [c022ffbc] device_add+0x1a8/0x51c
> [ef015db0] [c026be38] mdiobus_register+0xa0/0x1ac
> [ef015de0] [f224d5dc] mv643xx_eth_shared_probe+0x140/0x3f8 [mv643xx_eth]
> [ef015e00] [c0233dd0] platform_drv_probe+0x20/0x30
> [ef015e10] [c0232a4c] driver_probe_device+0xd4/0x1a8
> [ef015e30] [c0232b90] __driver_attach+0x70/0xa4
> [ef015e50] [c02320cc] bus_for_each_dev+0x5c/0xac
> [ef015e80] [c023285c] driver_attach+0x24/0x34
> [ef015e90] [c0231910] bus_add_driver+0xb4/0x248
> [ef015eb0] [c0232f78] driver_register+0xd0/0x174
> [ef015ed0] [c023412c] platform_driver_register+0x6c/0x7c
> [ef015ee0] [f2256024] mv643xx_eth_init_module+0x24/0x80 [mv643xx_eth]
> [ef015f00] [c0003ee0] do_one_initcall+0x64/0x1f8
> [ef015f20] [c0054680] sys_init_module+0xe0/0x224
> [ef015f40] [c0013828] ret_from_syscall+0x0/0x38
> --- Exception: c01 at 0xff69720
> LR = 0x10004150
> Instruction dump:
> 807d0000 7fe4fb78 4bffff51 3c80c03a 3884adb0 4bf3ce4d 809e0010 4bf3ce45
> 7c641b78 3c60c03b 38639868 48259099 <0fe00000> 7fe3fb78 4bfaac0d 80010024
> mii_bus 0 failed to register
> mv643xx_eth: probe of mv643xx_eth.0 failed with error -12
> Unable to handle kernel paging request for data at address 0x00000000
> Faulting instruction address: 0xf2250908
> Oops: Kernel access of bad area, sig: 11 [#1]
> PREEMPT CHRP
> Modules linked in: mv643xx_eth(+) via_rhine serio_raw parport firewire_core
> NIP: f2250908 LR: f2250900 CTR: c0232574
> REGS: ef015d10 TRAP: 0300 Tainted: G W (2.6.32.9)
> MSR: 00009032 <EE,ME,IR,DR> CR: 84422488 XER: 20000000
> DAR: 00000000, DSISR: 40000000
> TASK = ef082bc0[1011] 'modprobe' THREAD: ef014000
> GPR00: f22508f4 ef015dc0 ef082bc0 00000000 efb42300 efb42005 efb4214d 00000000
> GPR08: 00000000 00000001 2bfd0c6b c0232574 00000000 10020a5c 00000000 00000000
> GPR16: 00000000 00000000 100056bc 00000003 c0430230 00000000 00000000 00000000
> GPR24: c0430228 107fb57c 00000000 efb42000 f22528c0 fffffff4 c04300d8 efb42300
> NIP [f2250908] mv643xx_eth_probe+0xac/0x620 [mv643xx_eth]
> LR [f2250900] mv643xx_eth_probe+0xa4/0x620 [mv643xx_eth]
> Call Trace:
> [ef015dc0] [f22508f4] mv643xx_eth_probe+0x98/0x620 [mv643xx_eth] (unreliable)
> [ef015e00] [c0233dd0] platform_drv_probe+0x20/0x30
> [ef015e10] [c0232a4c] driver_probe_device+0xd4/0x1a8
> [ef015e30] [c0232b90] __driver_attach+0x70/0xa4
> [ef015e50] [c02320cc] bus_for_each_dev+0x5c/0xac
> [ef015e80] [c023285c] driver_attach+0x24/0x34
> [ef015e90] [c0231910] bus_add_driver+0xb4/0x248
> [ef015eb0] [c0232f78] driver_register+0xd0/0x174
> [ef015ed0] [c023412c] platform_driver_register+0x6c/0x7c
> [ef015ee0] [f2256034] mv643xx_eth_init_module+0x34/0x80 [mv643xx_eth]
> [ef015f00] [c0003ee0] do_one_initcall+0x64/0x1f8
> [ef015f20] [c0054680] sys_init_module+0xe0/0x224
> [ef015f40] [c0013828] ret_from_syscall+0x0/0x38
> --- Exception: c01 at 0xff69720
> LR = 0x10004150
> Instruction dump:
> 7c7b1b79 41820528 3bfb0300 3a980008 7e83a378 7fe4fb78 48000dd1 807e0000
> 38630008 480011b5 907b0300 813e0004 <80030000> 5529502a 39290400 7c004a14
> ---[ end trace 1a9241f24ee15efc ]---
Gabriel
^ permalink raw reply
* Re: [PATCH] irq: move some interrupt arch_* functions into struct irq_chip.
From: Ian Campbell @ 2010-03-10 17:41 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Jeremy Fitzhardinge, x86@kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@ozlabs.org, Ingo Molnar, Paul Mackerras,
H. Peter Anvin, Thomas Gleixner, Yinghai Lu
In-Reply-To: <m1r5nsjdsh.fsf@fess.ebiederm.org>
On Wed, 2010-03-10 at 17:18 +0000, Eric W. Biederman wrote:
> Ian Campbell <Ian.Campbell@citrix.com> writes:
>
> > On Wed, 2010-03-10 at 10:55 +0000, ijc@hellion.org.uk wrote:
> >>
> >> arch_init_chip_data cannot be moved into struct irq_chip at this time
> >> because irq_desc->chip is not known at the time the irq_desc is
> >> setup. For now rename arch_init_chip_data to arch_init_irq_desc (for
> >> PowerPC, the only other user, whose usage better matches the new name)
> >> and on x86 convert arch_init_chip_data to ioapic_init_chip_data and
> >> call this whenever the IO APIC code allocates a new IRQ.
> >
> > One idea I had to improve this was to add a struct irq_chip * as a
> > parameter to irq_to_desc_alloc_node. The new parameter potentially could
> > be NULL for current behaviour. Does that sound like a reasonable
> > approach?
>
> I don't follow why we have the restriction that irq_to_desc_alloc_node
> must call arch_init_chip_data. Assuming that requirement to call arch_init_chip_data
> is valid, passing something into init_one_irq_desc seems appropriate.
Yes, I suspect that could also be made to work.
The lifecycle of the irq_desc and chip_data isn't really clear to me --
I guess once allocated an irq_desc never gets freed (at least
currently)? The associated chip_data can be freed on migrate and
replaced with a new one, but is not freed otherwise.
My concern is that if the caller asks for an IRQ which already exists
(is that valid?) then you will get that existing irq_desc back,
including its existing chip_data, which potentially leaks the new one
which was passed in. Or is it the case that the only way this could
happen would be for legacy IRQs? In which case perhaps it is simply
invalid to pass a new chip data in for such an IRQ.
Ian.
^ permalink raw reply
* Re: [PATCH] irq: move some interrupt arch_* functions into struct irq_chip.
From: Eric W. Biederman @ 2010-03-10 17:42 UTC (permalink / raw)
To: Ian Campbell
Cc: Jeremy Fitzhardinge, x86@kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@ozlabs.org, Ingo Molnar, Paul Mackerras,
H. Peter Anvin, Thomas Gleixner, Yinghai Lu
In-Reply-To: <1268225473.11737.69196.camel@zakaz.uk.xensource.com>
Ian Campbell <Ian.Campbell@citrix.com> writes:
> On Wed, 2010-03-10 at 12:06 +0000, Yinghai Lu wrote:
>> On Wed, Mar 10, 2010 at 2:55 AM, <ijc@hellion.org.uk> wrote:
>> > From: Ian Campbell <ian.campbell@citrix.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 at this time
>> > because irq_desc->chip is not known at the time the irq_desc is
>> > setup. For now rename arch_init_chip_data to arch_init_irq_desc (for
>> > PowerPC, the only other user, whose usage better matches the new name)
>> > and on x86 convert arch_init_chip_data to ioapic_init_chip_data and
>> > call this whenever the IO APIC code allocates a new IRQ.
>> >
>> > 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
>> > ioapic_{init,copy,free}_chip_data functions could be static to
>> > io_apic.c.
>> >
>> > I've tested by booting on a 64 bit system, but it's not clear to me
>> > what actions I need to take to actually exercise some of these code
>> > paths.
>> >
>>
>> can you just add another pointer field in irq_desc?
>>
>> some kind of *irq_info etc.
>
> I think I don't understand what you are suggesting.
YH another field doesn't make much sense. Xen is a bizarre subarch
with an incompatible irq model. Xen simply needs the ability to
handle the entire lifetime of an irq_chip.
All we need between the Xen and the rest of x86 is a convention
so that we never manage the same irqs. At least for domU we are
in an either/or situation so I don't see even that being a problem.
> There is already a pointer for irq_chip specific use i.e.
> irq_desc->chip_data. This patchset is just about ensuring that the field
> really is available to any chip implementation rather than just assuming
> it is always used for the acpi chip types (on x86 at least).
Ian Xen in this sense is simply not x86. irq_cfg is not acpi or ioapic
or anything but x86 specific. It has everything to do with having a per
cpu vector table of 256 entries and architecturally receiving a vector
number when an interrupt is fired.
It totally makes sense for Xen to do something different because
architecturally it has a completely different irq subsystem.
At the same time let's not pretend that the reason for this is anything
except that Xen has a completely different notion of interrupt delivery
than the rest of x86 and so it is it's own bizarre subarch.
This is not a case where you simply need a driver because something is
a bit different but fits into the existing model.
So the best solution here seems to be a parameter that we pass into
irq_to_desc_alloc_node that does what is needed. The second best
would be to have arch_init_chip_data to call something like
platfrom_init_chip_data(). But I think we can avoid that in
this case.
Eric
^ permalink raw reply
* Re: [PATCH] irq: move some interrupt arch_* functions into struct irq_chip.
From: Ian Campbell @ 2010-03-10 17:50 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Jeremy Fitzhardinge, x86@kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@ozlabs.org, Ingo Molnar, Paul Mackerras,
H. Peter Anvin, Thomas Gleixner, Yinghai Lu
In-Reply-To: <m1iq94gjkf.fsf@fess.ebiederm.org>
On Wed, 2010-03-10 at 17:42 +0000, Eric W. Biederman wrote:
>
>
> Ian Xen in this sense is simply not x86. irq_cfg is not acpi or
> ioapic or anything but x86 specific. It has everything to do with
> having a per cpu vector table of 256 entries and architecturally
> receiving a vector number when an interrupt is fired.
>
> It totally makes sense for Xen to do something different because
> architecturally it has a completely different irq subsystem.
OK, so that sounds like you would like the same patchset but without the
irq_cfg renaming? or potentially with renaming to x86_blah instead (I'll
rework to your preference).
Ian.
^ permalink raw reply
* Re: [PATCH] irq: move some interrupt arch_* functions into struct irq_chip.
From: Eric W. Biederman @ 2010-03-10 18:11 UTC (permalink / raw)
To: Ian Campbell
Cc: Jeremy Fitzhardinge, x86@kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@ozlabs.org, Ingo Molnar, Paul Mackerras,
H. Peter Anvin, Thomas Gleixner, Yinghai Lu
In-Reply-To: <1268242912.11737.70762.camel@zakaz.uk.xensource.com>
Ian Campbell <Ian.Campbell@citrix.com> writes:
> On Wed, 2010-03-10 at 17:18 +0000, Eric W. Biederman wrote:
>> Ian Campbell <Ian.Campbell@citrix.com> writes:
>>
>> > On Wed, 2010-03-10 at 10:55 +0000, ijc@hellion.org.uk wrote:
>> >>
>> >> arch_init_chip_data cannot be moved into struct irq_chip at this time
>> >> because irq_desc->chip is not known at the time the irq_desc is
>> >> setup. For now rename arch_init_chip_data to arch_init_irq_desc (for
>> >> PowerPC, the only other user, whose usage better matches the new name)
>> >> and on x86 convert arch_init_chip_data to ioapic_init_chip_data and
>> >> call this whenever the IO APIC code allocates a new IRQ.
>> >
>> > One idea I had to improve this was to add a struct irq_chip * as a
>> > parameter to irq_to_desc_alloc_node. The new parameter potentially could
>> > be NULL for current behaviour. Does that sound like a reasonable
>> > approach?
>>
>> I don't follow why we have the restriction that irq_to_desc_alloc_node
>> must call arch_init_chip_data. Assuming that requirement to call arch_init_chip_data
>> is valid, passing something into init_one_irq_desc seems appropriate.
>
> Yes, I suspect that could also be made to work.
>
> The lifecycle of the irq_desc and chip_data isn't really clear to me --
> I guess once allocated an irq_desc never gets freed (at least
> currently)? The associated chip_data can be freed on migrate and
> replaced with a new one, but is not freed otherwise.
Yes. That actually looks like a bug.
> My concern is that if the caller asks for an IRQ which already exists
> (is that valid?) then you will get that existing irq_desc back,
> including its existing chip_data, which potentially leaks the new one
> which was passed in. Or is it the case that the only way this could
> happen would be for legacy IRQs? In which case perhaps it is simply
> invalid to pass a new chip data in for such an IRQ.
The only irqs that should be allocated/freed are probably the msi
irqs as those are the only ones that dynamically come and go in the
system.
Unfortunately there appears to be a bigger mess here than first appeared.
Eric
^ permalink raw reply
* Re: [PATCH] irq: move some interrupt arch_* functions into struct irq_chip.
From: Eric W. Biederman @ 2010-03-10 18:15 UTC (permalink / raw)
To: Ian Campbell
Cc: Jeremy Fitzhardinge, x86@kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@ozlabs.org, Ingo Molnar, Paul Mackerras,
H. Peter Anvin, Thomas Gleixner, Yinghai Lu
In-Reply-To: <1268243447.11737.70807.camel@zakaz.uk.xensource.com>
Ian Campbell <Ian.Campbell@citrix.com> writes:
> On Wed, 2010-03-10 at 17:42 +0000, Eric W. Biederman wrote:
>>
>>
>> Ian Xen in this sense is simply not x86. irq_cfg is not acpi or
>> ioapic or anything but x86 specific. It has everything to do with
>> having a per cpu vector table of 256 entries and architecturally
>> receiving a vector number when an interrupt is fired.
>>
>> It totally makes sense for Xen to do something different because
>> architecturally it has a completely different irq subsystem.
>
> OK, so that sounds like you would like the same patchset but without the
> irq_cfg renaming? or potentially with renaming to x86_blah instead (I'll
> rework to your preference).
Currently the renaming really makes it unclear what you are doing and for
some reason the description of the renaming rubbed me the wrong way.
Eric
^ permalink raw reply
* 5200B: BUG in 2.6.34-rc1-dirty while loading at24 driver
From: Albrecht Dreß @ 2010-03-10 18:25 UTC (permalink / raw)
To: Linux PPC Development
[-- Attachment #1: Type: text/plain, Size: 3643 bytes --]
Hi all,
not sure if this is the right place to ask: When I boot a custom 5200B (more or less Lite-based) board with Linus' git tree (2.6.34-rc1-dirty), I always get the following bug:
[ 1.110693] i2c /dev entries driver
[ 1.117285] mpc-i2c f0003d00.i2c: clock 375000 Hz (fdr=137)
[ 1.123156] mpc-i2c f0003d00.i2c: timeout 1000000 us
[ 1.146528] mpc-i2c f0003d40.i2c: clock 375000 Hz (fdr=137)
[ 1.152637] mpc-i2c f0003d40.i2c: timeout 1000000 us
[ 1.170628] rtc-ds1307 1-0068: rtc core: registered ds1337 as rtc0
[ 1.181003] BUG: key cf9ea5ac not in .data!
[ 1.185510] ------------[ cut here ]------------
[ 1.190257] Badness at kernel/lockdep.c:2706
[ 1.194627] NIP: c004d2b4 LR: c004d29c CTR: c01aeb30
[ 1.199714] REGS: cf82db70 TRAP: 0700 Not tainted (2.6.34-rc1-dirty)
[ 1.206483] MSR: 00029032 <EE,ME,CE,IR,DR> CR: 22084022 XER: 20000000
[ 1.213305] TASK = cf830000[1] 'swapper' THREAD: cf82c000
[ 1.218651] GPR00: 00000000 cf82dc20 cf830000 00000001 00000001 c0023fb4 00000000 00000001
[ 1.227243] GPR08: 00000000 c03f0000 c03c0000 00000001 42084024 100958e4 0ffef000 0ffe41a4
[ 1.235834] GPR16: 0ffbf298 0ffe4180 0ff72db4 0ff72cb4 c03d685c c03d6830 00000000 00000000
[ 1.244423] GPR24: fffffff4 00000001 c03f0000 00000080 cfa1c2d8 cf9ea5ac 00000000 cfa1c4d8
[ 1.253225] NIP [c004d2b4] lockdep_init_map+0xc4/0x4e4
[ 1.258489] LR [c004d29c] lockdep_init_map+0xac/0x4e4
[ 1.263657] Call Trace:
[ 1.266165] [cf82dc20] [c004d28c] lockdep_init_map+0x9c/0x4e4 (unreliable)
[ 1.273236] [cf82dc50] [c00de478] sysfs_add_file_mode+0x5c/0xe0
[ 1.279308] [cf82dc80] [c00e0bbc] sysfs_create_bin_file+0x34/0x50
[ 1.285575] [cf82dc90] [c01b8764] at24_probe+0x314/0x460
[ 1.291034] [cf82dcd0] [c0215768] i2c_device_probe+0xac/0xc0
[ 1.296840] [cf82dcf0] [c01b334c] driver_probe_device+0xa4/0x190
[ 1.303000] [cf82dd10] [c01b23c0] bus_for_each_drv+0x70/0xac
[ 1.308806] [cf82dd40] [c01b3620] device_attach+0x84/0xa8
[ 1.314343] [cf82dd60] [c01b1fd8] bus_probe_device+0x3c/0x54
[ 1.320166] [cf82dd70] [c01b0588] device_add+0x374/0x5f4
[ 1.325619] [cf82ddc0] [c0216ac4] i2c_new_device+0xf0/0x144
[ 1.331344] [cf82dde0] [c021b078] of_register_i2c_devices+0x12c/0x158
[ 1.337966] [cf82de60] [c02c1280] fsl_i2c_probe+0x190/0x324
[ 1.343687] [cf82de90] [c021abe8] of_platform_device_probe+0x5c/0x84
[ 1.350208] [cf82deb0] [c01b334c] driver_probe_device+0xa4/0x190
[ 1.356371] [cf82ded0] [c01b36e8] __driver_attach+0xa4/0xa8
[ 1.362087] [cf82def0] [c01b259c] bus_for_each_dev+0x60/0x9c
[ 1.367890] [cf82df20] [c01b3164] driver_attach+0x24/0x34
[ 1.373429] [cf82df30] [c01b2ef4] bus_add_driver+0x1a8/0x264
[ 1.379235] [cf82df60] [c01b3964] driver_register+0x6c/0x160
[ 1.385043] [cf82df80] [c021aac0] of_register_driver+0x54/0x70
[ 1.391040] [cf82df90] [c03ae9fc] fsl_i2c_init+0x24/0x54
[ 1.396497] [cf82dfa0] [c00038a0] do_one_initcall+0x40/0x1d4
[ 1.402305] [cf82dfd0] [c039a1e0] kernel_init+0xc4/0x16c
[ 1.407771] [cf82dff0] [c00110d8] kernel_thread+0x4c/0x68
[ 1.413300] Instruction dump:
[ 1.416341] 3863256c 4bfd758d 801ac11c 2f800000 40beffd4 48140b11 2f830000 41beffc8
[ 1.424309] 3d20c03f 8009c2a0 2f800000 40beffb8 <0fe00000> 80010034 bac10008 38210030
[ 1.432600] at24 1-0050: 65536 byte 24c512 EEPROM (writable)
Stock 2.6.33 runs flawlessly. Maybe I should add here that there is no eeprom connected to the I2C bus (just a placeholder in the dts file, for a chip on a separate board). Any idea what goes wrong here?
Thanks, Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [PATCH] irq: move some interrupt arch_* functions into struct irq_chip.
From: Ian Campbell @ 2010-03-10 18:28 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Jeremy Fitzhardinge, x86@kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@ozlabs.org, Ingo Molnar, Paul Mackerras,
H. Peter Anvin, Thomas Gleixner, Yinghai Lu
In-Reply-To: <m11vfsgi13.fsf@fess.ebiederm.org>
On Wed, 2010-03-10 at 18:15 +0000, Eric W. Biederman wrote:
> Ian Campbell <Ian.Campbell@citrix.com> writes:
>
> > On Wed, 2010-03-10 at 17:42 +0000, Eric W. Biederman wrote:
> >>
> >>
> >> Ian Xen in this sense is simply not x86. irq_cfg is not acpi or
> >> ioapic or anything but x86 specific. It has everything to do with
> >> having a per cpu vector table of 256 entries and architecturally
> >> receiving a vector number when an interrupt is fired.
> >>
> >> It totally makes sense for Xen to do something different because
> >> architecturally it has a completely different irq subsystem.
> >
> > OK, so that sounds like you would like the same patchset but without the
> > irq_cfg renaming? or potentially with renaming to x86_blah instead (I'll
> > rework to your preference).
>
> Currently the renaming really makes it unclear what you are doing and for
> some reason the description of the renaming rubbed me the wrong way.
Sorry, I started off a bit confused and then totally misunderstood what
related to what and I think that came through in the description.
I'll respin without the first patch.
Ian.
^ permalink raw reply
* Re: [PATCH] irq: move some interrupt arch_* functions into struct irq_chip.
From: Jeremy Fitzhardinge @ 2010-03-10 18:27 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Ian Campbell, x86@kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@ozlabs.org, Ingo Molnar, Paul Mackerras,
H. Peter Anvin, Thomas Gleixner, Yinghai Lu
In-Reply-To: <m1iq94gjkf.fsf@fess.ebiederm.org>
On 03/10/2010 09:42 AM, Eric W. Biederman wrote:
> All we need between the Xen and the rest of x86 is a convention
> so that we never manage the same irqs. At least for domU we are
> in an either/or situation so I don't see even that being a problem.
>
Dom0 too. This is part of the work implementing what we discussed a
while back - Xen now completely owns the local and IO apics, so dom0
only deals with Xen, not the hardware. Xen has a completely different
interrupt setup path, but at least it isn't a mishmash of Xen stuff and
native APIC stuff.
J
^ permalink raw reply
* Re: [PATCH] irq: move some interrupt arch_* functions into struct irq_chip.
From: Yinghai Lu @ 2010-03-10 18:59 UTC (permalink / raw)
To: Ian Campbell
Cc: Jeremy Fitzhardinge, x86@kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@ozlabs.org, Ingo Molnar, Paul Mackerras,
Eric W. Biederman, H. Peter Anvin, Thomas Gleixner
In-Reply-To: <1268225473.11737.69196.camel@zakaz.uk.xensource.com>
On 03/10/2010 04:51 AM, Ian Campbell wrote:
> On Wed, 2010-03-10 at 12:06 +0000, Yinghai Lu wrote:
>> On Wed, Mar 10, 2010 at 2:55 AM, <ijc@hellion.org.uk> wrote:
>>> From: Ian Campbell <ian.campbell@citrix.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 at this time
>>> because irq_desc->chip is not known at the time the irq_desc is
>>> setup. For now rename arch_init_chip_data to arch_init_irq_desc (for
>>> PowerPC, the only other user, whose usage better matches the new name)
>>> and on x86 convert arch_init_chip_data to ioapic_init_chip_data and
>>> call this whenever the IO APIC code allocates a new IRQ.
>>>
>>> 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
>>> ioapic_{init,copy,free}_chip_data functions could be static to
>>> io_apic.c.
>>>
>>> I've tested by booting on a 64 bit system, but it's not clear to me
>>> what actions I need to take to actually exercise some of these code
>>> paths.
>>>
>>
>> can you just add another pointer field in irq_desc?
>>
>> some kind of *irq_info etc.
>
> I think I don't understand what you are suggesting.
>
> There is already a pointer for irq_chip specific use i.e.
> irq_desc->chip_data. This patchset is just about ensuring that the field
> really is available to any chip implementation rather than just assuming
> it is always used for the acpi chip types (on x86 at least).
>
> Does adding a second pointer with the same (intended?) semantics as the
> existing one buy us anything?
#ifdef CONFIG_INTR_REMAP
struct irq_2_iommu *irq_2_iommu;
#endif
struct irq_chip *chip;
struct msi_desc *msi_desc;
we already have that for irq_2_iommu and msi_desc
YH
^ permalink raw reply
* Re: [PATCH] irq: move some interrupt arch_* functions into struct irq_chip.
From: Eric W. Biederman @ 2010-03-10 17:18 UTC (permalink / raw)
To: Ian Campbell
Cc: Jeremy Fitzhardinge, x86@kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@ozlabs.org, Ingo Molnar, Paul Mackerras,
H. Peter Anvin, Thomas Gleixner, Yinghai Lu
In-Reply-To: <1268218832.11737.68575.camel@zakaz.uk.xensource.com>
Ian Campbell <Ian.Campbell@citrix.com> writes:
> On Wed, 2010-03-10 at 10:55 +0000, ijc@hellion.org.uk wrote:
>>
>> arch_init_chip_data cannot be moved into struct irq_chip at this time
>> because irq_desc->chip is not known at the time the irq_desc is
>> setup. For now rename arch_init_chip_data to arch_init_irq_desc (for
>> PowerPC, the only other user, whose usage better matches the new name)
>> and on x86 convert arch_init_chip_data to ioapic_init_chip_data and
>> call this whenever the IO APIC code allocates a new IRQ.
>
> One idea I had to improve this was to add a struct irq_chip * as a
> parameter to irq_to_desc_alloc_node. The new parameter potentially could
> be NULL for current behaviour. Does that sound like a reasonable
> approach?
I don't follow why we have the restriction that irq_to_desc_alloc_node
must call arch_init_chip_data. Assuming that requirement to call arch_init_chip_data
is valid, passing something into init_one_irq_desc seems appropriate.
Eric
^ permalink raw reply
* Re: [PATCH] irq: move some interrupt arch_* functions into struct irq_chip.
From: Eric W. Biederman @ 2010-03-10 19:15 UTC (permalink / raw)
To: Yinghai Lu
Cc: Jeremy Fitzhardinge, Ian Campbell, x86@kernel.org,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
Ingo Molnar, Paul Mackerras, H. Peter Anvin, Thomas Gleixner
In-Reply-To: <4B97EC00.6030300@kernel.org>
Yinghai Lu <yinghai@kernel.org> writes:
> On 03/10/2010 04:51 AM, Ian Campbell wrote:
>> On Wed, 2010-03-10 at 12:06 +0000, Yinghai Lu wrote:
>>> On Wed, Mar 10, 2010 at 2:55 AM, <ijc@hellion.org.uk> wrote:
>>>> From: Ian Campbell <ian.campbell@citrix.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 at this time
>>>> because irq_desc->chip is not known at the time the irq_desc is
>>>> setup. For now rename arch_init_chip_data to arch_init_irq_desc (for
>>>> PowerPC, the only other user, whose usage better matches the new name)
>>>> and on x86 convert arch_init_chip_data to ioapic_init_chip_data and
>>>> call this whenever the IO APIC code allocates a new IRQ.
>>>>
>>>> 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
>>>> ioapic_{init,copy,free}_chip_data functions could be static to
>>>> io_apic.c.
>>>>
>>>> I've tested by booting on a 64 bit system, but it's not clear to me
>>>> what actions I need to take to actually exercise some of these code
>>>> paths.
>>>>
>>>
>>> can you just add another pointer field in irq_desc?
>>>
>>> some kind of *irq_info etc.
>>
>> I think I don't understand what you are suggesting.
>>
>> There is already a pointer for irq_chip specific use i.e.
>> irq_desc->chip_data. This patchset is just about ensuring that the field
>> really is available to any chip implementation rather than just assuming
>> it is always used for the acpi chip types (on x86 at least).
>>
>> Does adding a second pointer with the same (intended?) semantics as the
>> existing one buy us anything?
>
>
> #ifdef CONFIG_INTR_REMAP
> struct irq_2_iommu *irq_2_iommu;
> #endif
> struct irq_chip *chip;
> struct msi_desc *msi_desc;
>
> we already have that for irq_2_iommu and msi_desc
Those are at different levels of the hierarchy. Adding another pointer
for Xen is like having a different iommu and so adding another pointer
to handle that kind of iommu.
Eric
^ permalink raw reply
* [PATCH] powerpc: Build fix for mpc52xx
From: Jeff Mahoney @ 2010-03-10 21:03 UTC (permalink / raw)
To: linuxppc-dev
mpc52xx_gpt_wdt_setup is defined as 0, which causes the following build
failure with gcc 4.5, since it's built with -Werror.
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:761:3: error: statement with no effect
Defining it as do { } while(0) fixes the problem.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
---
arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
@@ -711,7 +711,7 @@ static int __devinit mpc52xx_gpt_wdt_ini
return 0;
}
-#define mpc52xx_gpt_wdt_setup(x, y) (0)
+#define mpc52xx_gpt_wdt_setup(x, y) do { } while(0)
#endif /* CONFIG_MPC5200_WDT */
--
Jeff Mahoney
SUSE Labs
^ permalink raw reply
* Re: [PATCH 05/13] powerpc/476: Add isync after loading mmu and debug spr's
From: Dave Kleikamp @ 2010-03-10 21:09 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev list, Torez Smith
In-Reply-To: <fb412d761003071508v15586071wf38bc1ae1ad17480@mail.gmail.com>
On Sun, 2010-03-07 at 15:08 -0800, Hollis Blanchard wrote:
> On Fri, Mar 5, 2010 at 12:43 PM, Dave Kleikamp
> <shaggy@linux.vnet.ibm.com> wrote:
> >
> > powerpc/476: Add isync after loading mmu and debug spr's
> >
> > From: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
> >
> > 476 requires an isync after loading MMU and debug related SPR's. Some of
> > these are in performance-critical paths and may need to be optimized, but
> > initially, we're playing it safe.
>
> Why is there sometimes #ifdef CONFIG_PPC_47x, sometimes not, and never
> the cputable infrastructure which was intended for this sort of thing?
The places without an ifdef are either in cpu initialization code, where
the cost of an isync is insignificant or, in one case, in 47x-specific
code.
I was having problems trying to get the cputable infrastructure
compiling in inline assembly in the *.c files, but I could have used
that in some places. Currently, one can't build with CONFIG_PPC_47x for
a non-47x cpu, and we want to re-evaluate whether we can get by without
these isyncs. So basically, I plan to clean this up somehow by the time
we have a working unified 44x/47x binary kernel.
Thanks,
Shaggy
--
David Kleikamp
IBM Linux Technology Center
^ permalink raw reply
* [PATCH 1/6] arch/powerpc/platforms/pseries: Use kasprintf
From: Julia Lawall @ 2010-03-10 21:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, linuxppc-dev,
linux-kernel, kernel-janitors
From: Julia Lawall <julia@diku.dk>
kasprintf combines kmalloc and sprintf, and takes care of the size
calculation itself.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression a,flag;
expression list args;
statement S;
@@
a =
- \(kmalloc\|kzalloc\)(...,flag)
+ kasprintf(flag,args)
<... when != a
if (a == NULL || ...) S
...>
- sprintf(a,args);
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
arch/powerpc/platforms/pseries/dlpar.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff -u -p a/arch/powerpc/platforms/pseries/dlpar.c b/arch/powerpc/platforms/pseries/dlpar.c
--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -78,13 +78,12 @@ static struct device_node *dlpar_parse_c
* prepend this to the full_name.
*/
name = (char *)ccwa + ccwa->name_offset;
- dn->full_name = kmalloc(strlen(name) + 2, GFP_KERNEL);
+ dn->full_name = kasprintf(GFP_KERNEL, "/%s", name);
if (!dn->full_name) {
kfree(dn);
return NULL;
}
- sprintf(dn->full_name, "/%s", name);
return dn;
}
@@ -409,15 +408,13 @@ static ssize_t dlpar_cpu_probe(const cha
* directory of the device tree. CPUs actually live in the
* cpus directory so we need to fixup the full_name.
*/
- cpu_name = kzalloc(strlen(dn->full_name) + strlen("/cpus") + 1,
- GFP_KERNEL);
+ cpu_name = kasprintf(GFP_KERNEL, "/cpus%s", dn->full_name);
if (!cpu_name) {
dlpar_free_cc_nodes(dn);
rc = -ENOMEM;
goto out;
}
- sprintf(cpu_name, "/cpus%s", dn->full_name);
kfree(dn->full_name);
dn->full_name = cpu_name;
^ permalink raw reply
* Re: [PATCH] irq: move some interrupt arch_* functions into struct irq_chip.
From: Michael Ellerman @ 2010-03-10 22:07 UTC (permalink / raw)
To: ijc
Cc: Jeremy Fitzhardinge, Ian Campbell, x86, linux-kernel,
linuxppc-dev, Ingo Molnar, Paul Mackerras, Eric W. Biederman,
H. Peter Anvin, Thomas Gleixner, Yinghai Lu
In-Reply-To: <1268218559-26784-2-git-send-email-ijc@hellion.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]
On Wed, 2010-03-10 at 10:55 +0000, ijc@hellion.org.uk wrote:
> From: Ian Campbell <ian.campbell@citrix.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 at this time
> because irq_desc->chip is not known at the time the irq_desc is
> setup. For now rename arch_init_chip_data to arch_init_irq_desc (for
> PowerPC, the only other user, whose usage better matches the new name)
> and on x86 convert arch_init_chip_data to ioapic_init_chip_data and
> call this whenever the IO APIC code allocates a new IRQ.
Ack on the name change, it should be called arch_init_irq_desc(), the
existing name clearly comes from the fact that sparse IRQ was
implemented first on x86, and on x86 that routine init's the chip data
for a new irq_desc.
But semantically arch_init_irq_desc() is the right name, I was just too
lazy to change it when I enabled sparse IRQ for powerpc.
Can't comment on the rest of the patch.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ 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