From: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: acpi-devel@lists.sourceforge.net,
Kenji Kaneshige <kaneshige.kenji@soft.fujitsu.com>,
akpm@osdl.org, greg@kroah.com, len.brown@intel.com,
tony.luck@intel.com, linux-kernel@vger.kernel.org,
linux-ia64@vger.kernel.org
Subject: Re: [ACPI] [PATCH] PCI IRQ resource deallocation support [2/3]
Date: Wed, 22 Sep 2004 10:24:40 +0900 [thread overview]
Message-ID: <4150D458.3050400@jp.fujitsu.com> (raw)
In-Reply-To: <200409210857.59457.bjorn.helgaas@hp.com>
Hi Bjorn,
Thank you for your feedbacks.
Bjorn Helgaas wrote:
> On Tuesday 21 September 2004 2:52 am, Kenji Kaneshige wrote:
>> + * This function undoes the effect of one call to acpi_register_gsi().
>> + * If this matches the last regstration, any IRQ resources for gsi
>
> s/regstration/registration/ (also other occurrences below).
Oops..
I'll fix these.
>
>> +void
>> +acpi_pci_irq_disable (
>> + struct pci_dev *dev)
>> +{
>> + unsigned char irq_disabled, irq;
>
> pci_dev.irq is unsigned int, not unsigned char, so irq_disabled
> should be unsigned int as well.
>
I'll fix this, thanks.
>> + * dev->irq is cleared by BIOS-assigned IRQ set during boot.
>> + */
>> + pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &irq);
>> + if (irq)
>> + pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);
>> + dev->irq = irq;
>
> Why do we need to fiddle with dev->irq? I think it should
> just be undefined after acpi_pci_irq_disable().
I had been considering what the "undefined dev->irq" was.
In fact, I had other ideas that was clearing it by zero or
-1 (0xffffffff). But I didn't know if we can use these values
as a undefined IRQ number. So I'm clearing it by the value
which was assigned by PCI core code (pci_read_irq()) before
acpi_pci_irq_enable() was called.
How do you think?
Thanks,
Kenji Kaneshige
WARNING: multiple messages have this Message-ID (diff)
From: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: acpi-devel@lists.sourceforge.net,
Kenji Kaneshige <kaneshige.kenji@soft.fujitsu.com>,
akpm@osdl.org, greg@kroah.com, len.brown@intel.com,
tony.luck@intel.com, linux-kernel@vger.kernel.org,
linux-ia64@vger.kernel.org
Subject: Re: [ACPI] [PATCH] PCI IRQ resource deallocation support [2/3]
Date: Wed, 22 Sep 2004 01:24:40 +0000 [thread overview]
Message-ID: <4150D458.3050400@jp.fujitsu.com> (raw)
In-Reply-To: <200409210857.59457.bjorn.helgaas@hp.com>
Hi Bjorn,
Thank you for your feedbacks.
Bjorn Helgaas wrote:
> On Tuesday 21 September 2004 2:52 am, Kenji Kaneshige wrote:
>> + * This function undoes the effect of one call to acpi_register_gsi().
>> + * If this matches the last regstration, any IRQ resources for gsi
>
> s/regstration/registration/ (also other occurrences below).
Oops..
I'll fix these.
>
>> +void
>> +acpi_pci_irq_disable (
>> + struct pci_dev *dev)
>> +{
>> + unsigned char irq_disabled, irq;
>
> pci_dev.irq is unsigned int, not unsigned char, so irq_disabled
> should be unsigned int as well.
>
I'll fix this, thanks.
>> + * dev->irq is cleared by BIOS-assigned IRQ set during boot.
>> + */
>> + pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &irq);
>> + if (irq)
>> + pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);
>> + dev->irq = irq;
>
> Why do we need to fiddle with dev->irq? I think it should
> just be undefined after acpi_pci_irq_disable().
I had been considering what the "undefined dev->irq" was.
In fact, I had other ideas that was clearing it by zero or
-1 (0xffffffff). But I didn't know if we can use these values
as a undefined IRQ number. So I'm clearing it by the value
which was assigned by PCI core code (pci_read_irq()) before
acpi_pci_irq_enable() was called.
How do you think?
Thanks,
Kenji Kaneshige
next prev parent reply other threads:[~2004-09-22 1:24 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-21 8:52 [PATCH] PCI IRQ resource deallocation support [2/3] Kenji Kaneshige
2004-09-21 8:52 ` Kenji Kaneshige
2004-09-21 8:52 ` Kenji Kaneshige
2004-09-21 14:57 ` [ACPI] " Bjorn Helgaas
2004-09-21 14:57 ` Bjorn Helgaas
2004-09-22 1:24 ` Kenji Kaneshige [this message]
2004-09-22 1:24 ` Kenji Kaneshige
[not found] ` <4150D458.3050400-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2004-09-24 5:52 ` Takayoshi Kochi
2004-09-24 5:52 ` [ACPI] " Takayoshi Kochi
2004-09-24 5:52 ` Takayoshi Kochi
[not found] ` <20040924.145229.108814142.t-kochi-UDFczIW9X1d8UrSeD/g0lQ@public.gmane.org>
2004-09-24 6:29 ` Kenji Kaneshige
2004-09-24 6:29 ` [ACPI] " Kenji Kaneshige
2004-09-24 6:29 ` Kenji Kaneshige
2004-09-24 20:39 ` Guennadi Liakhovetski
2004-09-24 20:39 ` Guennadi Liakhovetski
2004-09-27 5:01 ` Kenji Kaneshige
2004-09-27 5:01 ` Kenji Kaneshige
-- strict thread matches above, loose matches on Subject: below --
2004-09-21 8:52 [PATCH] PCI IRQ resource deallocation support [3/3] Kenji Kaneshige
2004-09-21 8:52 ` Kenji Kaneshige
2004-09-21 8:52 ` Kenji Kaneshige
2004-09-21 8:52 [PATCH] PCI IRQ resource deallocation support [1/3] Kenji Kaneshige
2004-09-21 8:52 ` Kenji Kaneshige
2004-09-21 8:52 ` Kenji Kaneshige
2004-09-21 8:52 [PATCH] PCI IRQ resource deallocation support [0/3] Kenji Kaneshige
2004-09-21 8:52 ` 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=4150D458.3050400@jp.fujitsu.com \
--to=kaneshige.kenji@jp.fujitsu.com \
--cc=acpi-devel@lists.sourceforge.net \
--cc=akpm@osdl.org \
--cc=bjorn.helgaas@hp.com \
--cc=greg@kroah.com \
--cc=kaneshige.kenji@soft.fujitsu.com \
--cc=len.brown@intel.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tony.luck@intel.com \
/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.