Re: [ACPI] [PATCH] PCI IRQ resource deallocation support [2/3]

From: Takayoshi Kochi (t-kochi_at_bq.jp.nec.com)
Date: 09/24/04

  • Next message: Luis R. Rodriguez: "Re: [1/1] connector: Kernel connector - userspace <-> kernelspace "linker"." 
    Date:	Fri, 24 Sep 2004 14:52:29 +0900 (JST)
To: kaneshige.kenji@jp.fujitsu.com

    From: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
    Subject: Re: [ACPI] [PATCH] PCI IRQ resource deallocation support [2/3]
    Date: Wed, 22 Sep 2004 10:24:40 +0900

    > >> + * 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.

    I think it has little sense in restoring value from the configuration
    space to dev->irq or clearing it.

    If we do preventive programming, it may be worth
    trying to define some magic constant (e.g. PCI_UNDEFINED_IRQ) and
    panic/BUG when the irq is being enabled.
    Otherwise, leaving dev->irq as it is would be ok. 

    ---
Takayoshi Kochi <t-kochi@bq.jp.nec.com>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
  • Next message: Luis R. Rodriguez: "Re: [1/1] connector: Kernel connector - userspace <-> kernelspace "linker"."

    Relevant Pages