From: ebiederm@xmission.com (Eric W. Biederman)
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
"x86@kernel.org" <x86@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linuxppc-dev@ozlabs.org" <linuxppc-dev@ozlabs.org>,
Ingo Molnar <mingo@redhat.com>, Paul Mackerras <paulus@samba.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Yinghai Lu <yinghai@kernel.org>
Subject: Re: [PATCH] irq: move some interrupt arch_* functions into struct irq_chip.
Date: Wed, 10 Mar 2010 09:18:38 -0800 [thread overview]
Message-ID: <m1r5nsjdsh.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <1268218832.11737.68575.camel@zakaz.uk.xensource.com> (Ian Campbell's message of "Wed\, 10 Mar 2010 11\:00\:32 +0000")
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
WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Yinghai Lu <yinghai@kernel.org>,
Jeremy Fitzhardinge <jeremy@goop.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
"x86\@kernel.org" <x86@kernel.org>,
"linuxppc-dev\@ozlabs.org" <linuxppc-dev@ozlabs.org>
Subject: Re: [PATCH] irq: move some interrupt arch_* functions into struct irq_chip.
Date: Wed, 10 Mar 2010 09:18:38 -0800 [thread overview]
Message-ID: <m1r5nsjdsh.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <1268218832.11737.68575.camel@zakaz.uk.xensource.com> (Ian Campbell's message of "Wed\, 10 Mar 2010 11\:00\:32 +0000")
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
next prev parent reply other threads:[~2010-03-10 19:09 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-03 3:31 x86: fix race in create_irq_nr on irq_desc Brandon Philips
2010-02-03 10:20 ` Yinghai Lu
2010-02-03 17:42 ` Brandon Philips
2010-02-03 19:31 ` Yinghai Lu
2010-02-04 3:17 ` Brandon Philips
2010-02-05 8:45 ` [PATCH] x86: keep chip_data in create_irq_nr Yinghai Lu
2010-02-05 21:05 ` Brandon Philips
2010-02-05 21:42 ` H. Peter Anvin
2010-02-05 21:09 ` [PATCH] x86: keep chip_data in create_irq_nr and destroy_irq Brandon Philips
2010-02-05 22:44 ` Yinghai Lu
2010-02-05 22:55 ` Brandon Philips
2010-02-06 0:06 ` Yinghai Lu
2010-02-06 0:18 ` [PATCH v2] " Brandon Philips
2010-02-06 6:42 ` [PATCH v3] " Brandon Philips
2010-02-06 7:16 ` Yinghai Lu
2010-02-06 20:05 ` Brandon Philips
2010-02-07 21:02 ` [PATCH v4] " Brandon Philips
2010-02-19 6:06 ` [tip:x86/urgent] x86, irq: Keep " tip-bot for Brandon Philips
2010-02-26 10:26 ` [tip:x86/irq] x86: apic: Fix mismerge, add arch_probe_nr_irqs() again tip-bot for Ingo Molnar
2010-02-26 18:19 ` Yinghai Lu
2010-02-27 9:10 ` Ingo Molnar
2010-02-27 9:37 ` Eric W. Biederman
2010-02-27 9:53 ` Ingo Molnar
2010-02-27 10:12 ` Eric W. Biederman
2010-03-01 11:22 ` Ian Campbell
2010-03-01 18:34 ` Eric W. Biederman
2010-03-01 21:44 ` Ian Campbell
2010-03-01 21:58 ` Eric W. Biederman
2010-03-02 8:31 ` Thomas Gleixner
2010-03-10 10:55 ` Ian Campbell
2010-03-10 10:55 ` [PATCH] x86: namespace some I/O APIC related structures and functions ijc
2010-03-10 17:07 ` Eric W. Biederman
2010-03-10 10:55 ` [PATCH] irq: move some interrupt arch_* functions into struct irq_chip ijc
2010-03-10 10:55 ` ijc
2010-03-10 11:00 ` Ian Campbell
2010-03-10 11:00 ` Ian Campbell
2010-03-10 17:18 ` Eric W. Biederman [this message]
2010-03-10 17:18 ` Eric W. Biederman
2010-03-10 17:41 ` Ian Campbell
2010-03-10 17:41 ` Ian Campbell
2010-03-10 18:11 ` Eric W. Biederman
2010-03-10 18:11 ` Eric W. Biederman
2010-03-10 12:06 ` Yinghai Lu
2010-03-10 12:06 ` Yinghai Lu
2010-03-10 12:51 ` Ian Campbell
2010-03-10 12:51 ` Ian Campbell
2010-03-10 17:42 ` Eric W. Biederman
2010-03-10 17:42 ` Eric W. Biederman
2010-03-10 17:50 ` Ian Campbell
2010-03-10 17:50 ` Ian Campbell
2010-03-10 18:15 ` Eric W. Biederman
2010-03-10 18:15 ` Eric W. Biederman
2010-03-10 18:28 ` Ian Campbell
2010-03-10 18:28 ` Ian Campbell
2010-03-10 18:27 ` Jeremy Fitzhardinge
2010-03-10 18:27 ` Jeremy Fitzhardinge
2010-03-10 18:59 ` Yinghai Lu
2010-03-10 18:59 ` Yinghai Lu
2010-03-10 19:15 ` Eric W. Biederman
2010-03-10 19:15 ` Eric W. Biederman
2010-03-10 22:07 ` Michael Ellerman
2010-03-10 22:07 ` Michael Ellerman
2010-03-10 10:55 ` [PATCH] x86: irq_desc->chip_data is always correct whether or not SPARSE_IRQ is enabled ijc
2010-03-01 22:01 ` [tip:x86/irq] x86: apic: Fix mismerge, add arch_probe_nr_irqs() again Jeremy Fitzhardinge
2010-02-27 12:57 ` [tip:x86/apic] " tip-bot for Ingo Molnar
2010-02-03 10:32 ` x86: fix race in create_irq_nr on irq_desc Yinghai Lu
-- strict thread matches above, loose matches on Subject: below --
2010-03-12 9:44 [GITPULL+PATCH 0/2] irq: move some interrupt arch_* functions into struct irq_chip Ian Campbell
2010-03-12 9:45 ` [PATCH] " Ian Campbell
2010-03-12 9:45 ` Ian Campbell
2010-03-12 19:26 ` Yinghai Lu
2010-03-12 19:26 ` Yinghai Lu
2010-03-13 0:29 ` Eric W. Biederman
2010-03-13 0:29 ` Eric W. Biederman
2010-03-16 8:50 ` Ian Campbell
2010-03-16 8:50 ` Ian Campbell
2010-03-16 9:18 ` Eric W. Biederman
2010-03-16 9:18 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1r5nsjdsh.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=Ian.Campbell@citrix.com \
--cc=hpa@zytor.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=mingo@redhat.com \
--cc=paulus@samba.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=yinghai@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.