From: Kristen Accardi <kristen.c.accardi@intel.com>
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: acpi-devel@lists.sourceforge.net, greg@kroah.com,
pcihpd-discuss@lists.sourceforge.net,
linux-kernel@vger.kernel.org, "Shah,
Rajesh" <rajesh.shah@intel.com>,
"Brown, Len" <len.brown@intel.com>
Subject: Re: [ACPI] Re: [Pcihpd-discuss] RE: [patch 2/2] acpi: add ability to derive irq when doing a surpriseremoval of an adapter
Date: Wed, 19 Oct 2005 09:51:51 -0700 [thread overview]
Message-ID: <1129740711.31966.21.camel@whizzy> (raw)
In-Reply-To: <200510190929.06728.bjorn.helgaas@hp.com>
On Wed, 2005-10-19 at 09:29 -0600, Bjorn Helgaas wrote:
> On Tuesday 18 October 2005 5:57 pm, Kristen Accardi wrote:
> > For surprise hotplug removal, the interrupt pin must be guessed, as any
> > attempts to read it would obviously be invalid. This patch adds a new
> > function to cycle through all possible pin values, and tries to either
> > lookup or derive the right irq to disable.
>
> I don't really like this because it adds a new path that's only
> used for "surprise" removals. So we have acpi_pci_irq_disable(),
> which is used for normal removals, and acpi_pci_irq_disable_nodev()
> for the surprise path. That feels like a maintenance problem.
>
> Other, non-ACPI, IRQ routing schemes should have the same problem
> (needing to know the interrupt pin after the device has been removed),
> so maybe the pin needs to be cached in the pci_dev?
This seems like a good idea to me, if nobody objects to adding another
field to pci_dev, I can change the patch to do this and resubmit.
next prev parent reply other threads:[~2005-10-19 16:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-08 0:56 [patch 2/2] acpi: add ability to derive irq when doing a surpriseremoval of an adapter Li, Shaohua
2005-10-10 17:48 ` Kristen Accardi
2005-10-11 17:54 ` Kristen Accardi
2005-10-18 23:57 ` [Pcihpd-discuss] " Kristen Accardi
2005-10-19 15:29 ` [ACPI] " Bjorn Helgaas
2005-10-19 16:51 ` Kristen Accardi [this message]
2005-10-19 16:59 ` Greg KH
2005-10-21 21:28 ` Kristen Accardi
2005-10-22 3:14 ` Bjorn Helgaas
2005-10-19 17:06 ` Matthew Wilcox
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=1129740711.31966.21.camel@whizzy \
--to=kristen.c.accardi@intel.com \
--cc=acpi-devel@lists.sourceforge.net \
--cc=bjorn.helgaas@hp.com \
--cc=greg@kroah.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pcihpd-discuss@lists.sourceforge.net \
--cc=rajesh.shah@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox