From: Kristen Accardi <kristen.c.accardi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: "Li, Shaohua" <shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: pcihpd-discuss-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
"Shah,
Rajesh" <rajesh.shah-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org, "Brown,
Len" <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Subject: RE: [patch 2/2] acpi: add ability to derive irq when doing a surpriseremoval of an adapter
Date: Mon, 10 Oct 2005 10:48:53 -0700 [thread overview]
Message-ID: <1128966533.13328.3.camel@whizzy> (raw)
In-Reply-To: <59D45D057E9702469E5775CBB56411F190A57F@pdsmsx406>
On Fri, 2005-10-07 at 17:56 -0700, Li, Shaohua wrote:
> Hi,
> >
> >If an adapter is surprise removed, the interrupt pin must be guessed,
> as
> >any attempts to read it would obviously be invalid. cycle through all
> >possible interrupt pin values until we can either lookup or derive the
> >right irq to disable.
> >
> >Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> >
> >diff -uprN -X linux-2.6.14-rc2/Documentation/dontdiff linux-2.6.14-
> >rc2/drivers/acpi/pci_irq.c linux-2.6.14-rc2-kca1/drivers/acpi/pci_irq.c
> >--- linux-2.6.14-rc2/drivers/acpi/pci_irq.c 2005-09-27
> >09:01:28.000000000 -0700
> >+++ linux-2.6.14-rc2-kca1/drivers/acpi/pci_irq.c 2005-09-28
> >10:40:57.000000000 -0700
> >@@ -491,6 +491,79 @@ void __attribute__ ((weak)) acpi_unregis
> > {
> > }
> >
> >+
> >+
> >+/*
> >+ * This function will be called only in the case of
> >+ * a "surprise" hot plug removal. For surprise removals,
> >+ * the card has either already be yanked out of the slot, or
> >+ * the slot's been powered off, so we have to brute force
> >+ * our way through all the possible interrupt pins to derive
> >+ * the GSI, then we double check with the value stored in the
> >+ * pci_dev structure to make sure we have the GSI that belongs
> >+ * to this IRQ.
> >+ */
> >+void acpi_pci_irq_disable_nodev(struct pci_dev *dev)
> >+{
> >+ int gsi = 0;
> >+ u8 pin = 0;
> >+ int edge_level = ACPI_LEVEL_SENSITIVE;
> >+ int active_high_low = ACPI_ACTIVE_LOW;
> >+ int irq;
> >+
> >+ /*
> >+ * since our device is not present, we
> >+ * can't just read the interrupt pin
> >+ * and use the value to derive the irq.
> >+ * in this case, we are going to check
> >+ * each returned irq value to make
> >+ * sure it matches our already assigned
> >+ * irq before we use it.
> >+ */
> >+ for (pin = 0; pin < 4; pin++) {
> >+ /*
> >+ * First we check the PCI IRQ routing table (PRT) for an
> IRQ.
> >+ */
> >+ gsi = acpi_pci_irq_lookup(dev->bus,
> PCI_SLOT(dev->devfn), pin,
> >+ &edge_level, &active_high_low, NULL,
> >+ acpi_pci_free_irq);
> acpi_pci_free_irq has side effect. In the link device case, it
> deferences a count. The blind guess will mass the reference count. Could
> you introduce something like 'acpi_pci_find_irq'?
>
> Thanks,
> Shaohua
Is the ref count decrement in pci-link.c in this section of code:
#ifdef FUTURE_USE
/*
* The Link reference count allows us to _DISable an unused link
* and suspend time, and set it again on resume.
* However, 2.6.12 still has irq_router.resume
* which blindly restores the link state.
* So we disable the reference count method
* to prevent duplicate acpi_pci_link_set()
* which would harm some systems
*/
link->refcnt--;
#endif
Or is it somewhere else? Just want to make sure I know where I need to
avoid calling into.
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
WARNING: multiple messages have this Message-ID (diff)
From: Kristen Accardi <kristen.c.accardi@intel.com>
To: "Li, Shaohua" <shaohua.li@intel.com>
Cc: pcihpd-discuss@lists.sourceforge.net,
linux-kernel@vger.kernel.org, acpi-devel@lists.sourceforge.net,
"Shah, Rajesh" <rajesh.shah@intel.com>,
greg@kroah.com, "Brown, Len" <len.brown@intel.com>
Subject: RE: [patch 2/2] acpi: add ability to derive irq when doing a surpriseremoval of an adapter
Date: Mon, 10 Oct 2005 10:48:53 -0700 [thread overview]
Message-ID: <1128966533.13328.3.camel@whizzy> (raw)
In-Reply-To: <59D45D057E9702469E5775CBB56411F190A57F@pdsmsx406>
On Fri, 2005-10-07 at 17:56 -0700, Li, Shaohua wrote:
> Hi,
> >
> >If an adapter is surprise removed, the interrupt pin must be guessed,
> as
> >any attempts to read it would obviously be invalid. cycle through all
> >possible interrupt pin values until we can either lookup or derive the
> >right irq to disable.
> >
> >Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
> >
> >diff -uprN -X linux-2.6.14-rc2/Documentation/dontdiff linux-2.6.14-
> >rc2/drivers/acpi/pci_irq.c linux-2.6.14-rc2-kca1/drivers/acpi/pci_irq.c
> >--- linux-2.6.14-rc2/drivers/acpi/pci_irq.c 2005-09-27
> >09:01:28.000000000 -0700
> >+++ linux-2.6.14-rc2-kca1/drivers/acpi/pci_irq.c 2005-09-28
> >10:40:57.000000000 -0700
> >@@ -491,6 +491,79 @@ void __attribute__ ((weak)) acpi_unregis
> > {
> > }
> >
> >+
> >+
> >+/*
> >+ * This function will be called only in the case of
> >+ * a "surprise" hot plug removal. For surprise removals,
> >+ * the card has either already be yanked out of the slot, or
> >+ * the slot's been powered off, so we have to brute force
> >+ * our way through all the possible interrupt pins to derive
> >+ * the GSI, then we double check with the value stored in the
> >+ * pci_dev structure to make sure we have the GSI that belongs
> >+ * to this IRQ.
> >+ */
> >+void acpi_pci_irq_disable_nodev(struct pci_dev *dev)
> >+{
> >+ int gsi = 0;
> >+ u8 pin = 0;
> >+ int edge_level = ACPI_LEVEL_SENSITIVE;
> >+ int active_high_low = ACPI_ACTIVE_LOW;
> >+ int irq;
> >+
> >+ /*
> >+ * since our device is not present, we
> >+ * can't just read the interrupt pin
> >+ * and use the value to derive the irq.
> >+ * in this case, we are going to check
> >+ * each returned irq value to make
> >+ * sure it matches our already assigned
> >+ * irq before we use it.
> >+ */
> >+ for (pin = 0; pin < 4; pin++) {
> >+ /*
> >+ * First we check the PCI IRQ routing table (PRT) for an
> IRQ.
> >+ */
> >+ gsi = acpi_pci_irq_lookup(dev->bus,
> PCI_SLOT(dev->devfn), pin,
> >+ &edge_level, &active_high_low, NULL,
> >+ acpi_pci_free_irq);
> acpi_pci_free_irq has side effect. In the link device case, it
> deferences a count. The blind guess will mass the reference count. Could
> you introduce something like 'acpi_pci_find_irq'?
>
> Thanks,
> Shaohua
Is the ref count decrement in pci-link.c in this section of code:
#ifdef FUTURE_USE
/*
* The Link reference count allows us to _DISable an unused link
* and suspend time, and set it again on resume.
* However, 2.6.12 still has irq_router.resume
* which blindly restores the link state.
* So we disable the reference count method
* to prevent duplicate acpi_pci_link_set()
* which would harm some systems
*/
link->refcnt--;
#endif
Or is it somewhere else? Just want to make sure I know where I need to
avoid calling into.
next prev parent reply other threads:[~2005-10-10 17:48 UTC|newest]
Thread overview: 14+ 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-08 0:56 ` Li, Shaohua
2005-10-10 17:48 ` Kristen Accardi [this message]
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
2005-10-19 16:59 ` Greg KH
2005-10-21 21:28 ` Kristen Accardi
2005-10-22 3:14 ` Bjorn Helgaas
2005-10-22 3:14 ` Bjorn Helgaas
2005-10-19 17:06 ` Matthew Wilcox
2005-10-19 17:06 ` [ACPI] " 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=1128966533.13328.3.camel@whizzy \
--to=kristen.c.accardi-ral2jqcrhueavxtiumwx3w@public.gmane.org \
--cc=acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
--cc=greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org \
--cc=len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=pcihpd-discuss-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
--cc=rajesh.shah-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.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.