From: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
To: Zwane Mwaikambo <zwane@linuxpower.ca>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
long <tlnguyen@snoqualmie.dp.intel.com>,
Andrew Morton <akpm@osdl.org>,
Greg Kroah-Hartmann <greg@kroah.com>,
Len Brown <len.brown@intel.com>,
tony.luck@intel.com, acpi-devel@lists.sourceforge.net,
linux-ia64@vger.kernel.org
Subject: Re: [ACPI] [PATCH] Updated patches for PCI IRQ resource deallocation support [2/3]
Date: Mon, 27 Sep 2004 14:49:11 +0900 [thread overview]
Message-ID: <4157A9D7.4090605@jp.fujitsu.com> (raw)
In-Reply-To: <Pine.LNX.4.53.0409251416570.2908@musoma.fsmlabs.com>
Zwane Mwaikambo wrote:
> On Sat, 25 Sep 2004, Zwane Mwaikambo wrote:
>
>> Kenji Kaneshige wrote:
>>
>> > - Changed acpi_pci_irq_disable() to leave 'dev->irq' as it
>> > is. Clearing 'dev->irq' by some magic constant
>> > (e.g. PCI_UNDEFINED_IRQ) is TBD.
>>
>> This may not be safe with CONFIG_PCI_MSI, you may want to verify against
>> that if you already haven't.
>>
Thank you for commemts.
You are right. If the linux IRQ number is allocated by MSI code,
clearing 'dev->irq' would cause a problem. So we need to consider
clearing 'dev->irq' carefully.
The latest patch doesn't clear 'dev->irq' so far.
>> > +acpi_unregister_gsi (unsigned int irq)
>> > +{
>> > +}
>> > +EXPORT_SYMBOL(acpi_unregister_gsi);
>>
>> Why not just make these static inlines in header files? Since you're on
>> this, how about making irq_desc and friends dynamic too?
>
> Sorry, i broke Cc.
>
I'm not quite sure what you are saying, but my idea is defining
acpi_unregister_gsi() as a opposite part of acpi_register_gsi().
Acpi_register_gsi() is defined for each arch (i386, ia64), so
acpi_unregister_gsi() is defined for each i386 and ia64 too.
Thanks,
Kenji Kaneshige
WARNING: multiple messages have this Message-ID (diff)
From: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
To: Zwane Mwaikambo <zwane@linuxpower.ca>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
long <tlnguyen@snoqualmie.dp.intel.com>,
Andrew Morton <akpm@osdl.org>,
Greg Kroah-Hartmann <greg@kroah.com>,
Len Brown <len.brown@intel.com>,
tony.luck@intel.com, acpi-devel@lists.sourceforge.net,
linux-ia64@vger.kernel.org
Subject: Re: [ACPI] [PATCH] Updated patches for PCI IRQ resource deallocation
Date: Mon, 27 Sep 2004 05:49:11 +0000 [thread overview]
Message-ID: <4157A9D7.4090605@jp.fujitsu.com> (raw)
In-Reply-To: <Pine.LNX.4.53.0409251416570.2908@musoma.fsmlabs.com>
Zwane Mwaikambo wrote:
> On Sat, 25 Sep 2004, Zwane Mwaikambo wrote:
>
>> Kenji Kaneshige wrote:
>>
>> > - Changed acpi_pci_irq_disable() to leave 'dev->irq' as it
>> > is. Clearing 'dev->irq' by some magic constant
>> > (e.g. PCI_UNDEFINED_IRQ) is TBD.
>>
>> This may not be safe with CONFIG_PCI_MSI, you may want to verify against
>> that if you already haven't.
>>
Thank you for commemts.
You are right. If the linux IRQ number is allocated by MSI code,
clearing 'dev->irq' would cause a problem. So we need to consider
clearing 'dev->irq' carefully.
The latest patch doesn't clear 'dev->irq' so far.
>> > +acpi_unregister_gsi (unsigned int irq)
>> > +{
>> > +}
>> > +EXPORT_SYMBOL(acpi_unregister_gsi);
>>
>> Why not just make these static inlines in header files? Since you're on
>> this, how about making irq_desc and friends dynamic too?
>
> Sorry, i broke Cc.
>
I'm not quite sure what you are saying, but my idea is defining
acpi_unregister_gsi() as a opposite part of acpi_register_gsi().
Acpi_register_gsi() is defined for each arch (i386, ia64), so
acpi_unregister_gsi() is defined for each i386 and ia64 too.
Thanks,
Kenji Kaneshige
next prev parent reply other threads:[~2004-09-27 5:49 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.53.0409251356110.2914@musoma.fsmlabs.com>
2004-09-25 11:14 ` [ACPI] [PATCH] Updated patches for PCI IRQ resource deallocation support [2/3] Zwane Mwaikambo
2004-09-25 11:18 ` Zwane Mwaikambo
2004-09-25 11:18 ` [ACPI] [PATCH] Updated patches for PCI IRQ resource deallocation Zwane Mwaikambo
2004-09-27 5:49 ` Kenji Kaneshige [this message]
2004-09-27 5:49 ` Kenji Kaneshige
2004-09-28 14:05 ` [ACPI] [PATCH] Updated patches for PCI IRQ resource deallocation support [2/3] Zwane Mwaikambo
2004-09-28 14:05 ` [ACPI] [PATCH] Updated patches for PCI IRQ resource deallocation Zwane Mwaikambo
2004-09-29 0:41 ` [ACPI] [PATCH] Updated patches for PCI IRQ resource deallocation support [2/3] Kenji Kaneshige
2004-09-29 0:41 ` [ACPI] [PATCH] Updated patches for PCI IRQ resource deallocation Kenji Kaneshige
2004-09-29 3:15 ` [ACPI] [PATCH] Updated patches for PCI IRQ resource deallocation support [2/3] Kenji Kaneshige
2004-09-29 3:15 ` [ACPI] [PATCH] Updated patches for PCI IRQ resource deallocation Kenji Kaneshige
2004-09-29 15:13 ` [ACPI] [PATCH] Updated patches for PCI IRQ resource deallocation support [2/3] Zwane Mwaikambo
2004-09-29 15:13 ` [ACPI] [PATCH] Updated patches for PCI IRQ resource deallocation Zwane Mwaikambo
2004-09-30 4:22 ` [ACPI] [PATCH] Updated patches for PCI IRQ resource deallocation support [2/3] Kenji Kaneshige
2004-09-30 4:22 ` [ACPI] [PATCH] Updated patches for PCI IRQ resource deallocation Kenji Kaneshige
2004-09-30 13:03 ` [ACPI] [PATCH] Updated patches for PCI IRQ resource deallocation support [2/3] Zwane Mwaikambo
2004-09-30 13:03 ` [ACPI] [PATCH] Updated patches for PCI IRQ resource deallocation Zwane Mwaikambo
2004-10-01 7:49 ` [ACPI] [PATCH] Updated patches for PCI IRQ resource deallocation support [2/3] Kenji Kaneshige
2004-10-01 7:49 ` [ACPI] [PATCH] Updated patches for PCI IRQ resource deallocation Kenji Kaneshige
2004-09-24 5:45 [PATCH] Updated patches for PCI IRQ resource deallocation support [2/3] Kenji Kaneshige
2004-09-24 8:18 ` [ACPI] " Kenji Kaneshige
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=4157A9D7.4090605@jp.fujitsu.com \
--to=kaneshige.kenji@jp.fujitsu.com \
--cc=acpi-devel@lists.sourceforge.net \
--cc=akpm@osdl.org \
--cc=greg@kroah.com \
--cc=len.brown@intel.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tlnguyen@snoqualmie.dp.intel.com \
--cc=tony.luck@intel.com \
--cc=zwane@linuxpower.ca \
/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.