public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
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

  reply	other threads:[~2005-10-10 17:48 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 [this message]
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-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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox