From: Greg KH <gregkh@suse.de>
To: Len Brown <lenb@kernel.org>
Cc: Andrew Morton <akpm@osdl.org>, John Keller <jpk@sgi.com>,
linux-acpi@vger.kernel.org, tony.luck@intel.com,
linux-ia64@vger.kernel.org, pcihpd-discuss@lists.sourceforge.net,
linux-kernel@vger.kernel.org, ayoung@sgi.com, jes@sgi.com,
"Starikovskiy, Alexey" <alexey.y.starikovskiy@linux.intel.com>
Subject: Re: [PATCH 3/3] Altix: Add ACPI SSDT PCI device support (hotplug)
Date: Mon, 29 Jan 2007 16:12:24 -0800 [thread overview]
Message-ID: <20070130001224.GA7238@suse.de> (raw)
In-Reply-To: <200701270204.43835.lenb@kernel.org>
On Sat, Jan 27, 2007 at 02:04:43AM -0500, Len Brown wrote:
> From: John Keller <jpk@sgi.com>
>
> Support for dynamic loading and unloading of ACPI SSDT tables upon slot
> hotplugs and unplugs.
>
> On SN platforms, we now represent every populated root bus slot with a single
> ACPI SSDT table containing info for every device and PPB attached to the slot.
> These SSDTs are generated by the prom at initial boot and hotplug time. The
> info in these SSDT tables is used by the SN kernel IO "fixup" code (which is
> called at boot and hotplug time).
>
> On hotplugs (i.e. enable_slot()), if running with an ACPI capable prom,
> attempt to obtain a new ACPI SSDT table for the slot being hotplugged. If
> successful, add the table to the ACPI namespace (acpi_load_table()) and then
> walk the new devices and add them to the ACPI infrastructure (acpi_bus_add()).
>
> On hot unplugs (i.e. disable_slot()), if running with an ACPI capable prom,
> attempt to remove the SSDT table associated with the slot from the ACPI
> namespace (acpi_unload_table_id()) and infastructure (acpi_bus_trim()).
>
> From: John Keller <jpk@sgi.com>
>
> A bug was fixed where the sgi hotplug driver was removing
> the slot's SSDT table from the ACPI namespace a bit too early in
> disable_slot(). Also, we now call acpi_bus_start() subsequent
> to acpi_bus_add().
>
> Signed-off-by: Aaron Young <ayoung@sgi.com>
> Cc: Greg KH <greg@kroah.com>
This should go through Kristen, as she is now the pci hotplug
maintainer, not I.
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@suse.de>
To: Len Brown <lenb@kernel.org>
Cc: Andrew Morton <akpm@osdl.org>, John Keller <jpk@sgi.com>,
linux-acpi@vger.kernel.org, tony.luck@intel.com,
linux-ia64@vger.kernel.org, pcihpd-discuss@lists.sourceforge.net,
linux-kernel@vger.kernel.org, ayoung@sgi.com, jes@sgi.com,
"Starikovskiy, Alexey" <alexey.y.starikovskiy@linux.intel.com>
Subject: Re: [PATCH 3/3] Altix: Add ACPI SSDT PCI device support (hotplug)
Date: Tue, 30 Jan 2007 00:12:24 +0000 [thread overview]
Message-ID: <20070130001224.GA7238@suse.de> (raw)
In-Reply-To: <200701270204.43835.lenb@kernel.org>
On Sat, Jan 27, 2007 at 02:04:43AM -0500, Len Brown wrote:
> From: John Keller <jpk@sgi.com>
>
> Support for dynamic loading and unloading of ACPI SSDT tables upon slot
> hotplugs and unplugs.
>
> On SN platforms, we now represent every populated root bus slot with a single
> ACPI SSDT table containing info for every device and PPB attached to the slot.
> These SSDTs are generated by the prom at initial boot and hotplug time. The
> info in these SSDT tables is used by the SN kernel IO "fixup" code (which is
> called at boot and hotplug time).
>
> On hotplugs (i.e. enable_slot()), if running with an ACPI capable prom,
> attempt to obtain a new ACPI SSDT table for the slot being hotplugged. If
> successful, add the table to the ACPI namespace (acpi_load_table()) and then
> walk the new devices and add them to the ACPI infrastructure (acpi_bus_add()).
>
> On hot unplugs (i.e. disable_slot()), if running with an ACPI capable prom,
> attempt to remove the SSDT table associated with the slot from the ACPI
> namespace (acpi_unload_table_id()) and infastructure (acpi_bus_trim()).
>
> From: John Keller <jpk@sgi.com>
>
> A bug was fixed where the sgi hotplug driver was removing
> the slot's SSDT table from the ACPI namespace a bit too early in
> disable_slot(). Also, we now call acpi_bus_start() subsequent
> to acpi_bus_add().
>
> Signed-off-by: Aaron Young <ayoung@sgi.com>
> Cc: Greg KH <greg@kroah.com>
This should go through Kristen, as she is now the pci hotplug
maintainer, not I.
thanks,
greg k-h
next prev parent reply other threads:[~2007-01-30 0:12 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-15 15:24 [PATCH 1/3] - Altix: ACPI SSDT PCI device support John Keller
2006-11-15 15:24 ` John Keller
2007-01-27 1:10 ` Andrew Morton
2007-01-27 1:10 ` Andrew Morton
2007-01-27 6:55 ` Len Brown
2007-01-27 6:55 ` Len Brown
2007-01-27 6:57 ` [PATCH 1/3] - ACPICA: reduce conflicts with Altix patch series Len Brown
2007-01-27 6:57 ` Len Brown
2007-01-27 7:03 ` [PATCH 2/3] Altix: ACPI SSDT PCI device support Len Brown
2007-01-27 7:03 ` Len Brown
2007-01-27 7:04 ` [PATCH 3/3] Altix: Add ACPI SSDT PCI device support (hotplug) Len Brown
2007-01-27 7:04 ` Len Brown
2007-01-30 0:12 ` Greg KH [this message]
2007-01-30 0:12 ` Greg KH
-- strict thread matches above, loose matches on Subject: below --
2006-12-04 23:32 [patch " akpm
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=20070130001224.GA7238@suse.de \
--to=gregkh@suse.de \
--cc=akpm@osdl.org \
--cc=alexey.y.starikovskiy@linux.intel.com \
--cc=ayoung@sgi.com \
--cc=jes@sgi.com \
--cc=jpk@sgi.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pcihpd-discuss@lists.sourceforge.net \
--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.