Revision tags: v3.4-rc7, v3.4-rc6, v3.4-rc5, v3.4-rc4, v3.4-rc3, v3.4-rc2, v3.4-rc1, v3.3, v3.3-rc7, v3.3-rc6 |
|
#
f6330c31 |
| 25-Feb-2012 |
Yinghai Lu <yinghai@kernel.org> |
PCI: make acpihp use __pci_remove_bus_device instead
pci_stop_bus_device gets called before in the same loop.
Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@vir
PCI: make acpihp use __pci_remove_bus_device instead
pci_stop_bus_device gets called before in the same loop.
Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
show more ...
|
#
210647af |
| 25-Feb-2012 |
Yinghai Lu <yinghai@kernel.org> |
PCI: Rename pci_remove_bus_device to pci_stop_and_remove_bus_device
The old pci_remove_bus_device actually did stop and remove.
Make the name reflect that to reduce confusion.
This patch is done b
PCI: Rename pci_remove_bus_device to pci_stop_and_remove_bus_device
The old pci_remove_bus_device actually did stop and remove.
Make the name reflect that to reduce confusion.
This patch is done by sed scripts and changes back some incorrect __pci_remove_bus_device changes.
Suggested-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
show more ...
|
Revision tags: v3.3-rc5, v3.3-rc4, v3.3-rc3, v3.3-rc2, v3.3-rc1, v3.2, v3.2-rc7, v3.2-rc6, v3.2-rc5, v3.2-rc4 |
|
#
f382a086 |
| 25-Nov-2011 |
Amos Kong <akong@redhat.com> |
PCI: Can continually add funcs after adding func0
Boot up a KVM guest, and hotplug multifunction devices(func1,func2,func0,func3) to guest.
for i in 1 2 0 3;do qemu-img create /tmp/resize$i.qcow2 1
PCI: Can continually add funcs after adding func0
Boot up a KVM guest, and hotplug multifunction devices(func1,func2,func0,func3) to guest.
for i in 1 2 0 3;do qemu-img create /tmp/resize$i.qcow2 1G -f qcow2 (qemu) drive_add 0x11.$i id=drv11$i,if=none,file=/tmp/resize$i.qcow2 (qemu) device_add virtio-blk-pci,id=dev11$i,drive=drv11$i,addr=0x11.$i,multifunction=on done
In linux kernel, when func0 of the slot is hot-added, the whole slot will be marked as 'enabled', then driver will ignore other new hotadded funcs. But in Win7 & WinXP, we can continaully add other funcs after adding func0, all funcs will be added in guest.
drivers/pci/hotplug/acpiphp_glue.c: static int acpiphp_check_bridge(struct acpiphp_bridge *bridge) { .... for (slot = bridge->slots; slot; slot = slot->next) { if (slot->flags & SLOT_ENABLED) { acpiphp_disable_slot() else acpiphp_enable_slot() .... | } v enable_device() | v //only don't enable slot if func0 is not added list_for_each_entry(func, &slot->funcs, sibling) { ... } slot->flags |= SLOT_ENABLED; //mark slot to 'enabled'
This patch just make pci driver can continaully add funcs after adding func 0. Only mark slot to 'enabled' when all funcs are added.
For pci multifunction hotplug, we can add functions one by one(func 0 is necessary), and all functions will be removed in one time.
Signed-off-by: Amos Kong <akong@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
show more ...
|
#
b51306c6 |
| 12-Dec-2011 |
Ajaykumar Hotchandani <ajaykumar.hotchandani@oracle.com> |
PCI: Set device power state to PCI_D0 for device without native PM support
During test of one IB card with guest VM, found that, msi is not initialized properly.
It turns out __write_msi_msg will d
PCI: Set device power state to PCI_D0 for device without native PM support
During test of one IB card with guest VM, found that, msi is not initialized properly.
It turns out __write_msi_msg will do nothing if device current_state is not PCI_D0. And, that pci device does not have pm_cap in guest VM.
There is an error in setting of power state to PCI_D0 in pci_enable_device(), but error is not returned for this. Following is code flow:
pci_enable_device() --> __pci_enable_device_flags() --> do_pci_enable_device() --> pci_set_power_state() --> __pci_start_power_transition()
We have following condition inside __pci_start_power_transition(): if (platform_pci_power_manageable(dev)) { error = platform_pci_set_power_state(dev, state); if (!error) pci_update_current_state(dev, state); } else { error = -ENODEV; /* Fall back to PCI_D0 if native PM is not supported */ if (!dev->pm_cap) dev->current_state = PCI_D0; }
Here, from platform_pci_set_power_state(), acpi_pci_set_power_state() is getting called and that is failing with ENODEV because of following condition:
if (!handle || ACPI_SUCCESS(acpi_get_handle(handle, "_EJ0",&tmp))) return -ENODEV;
Because of that, pci_update_current_state() is not getting called.
With this patch, if device power state can not be set via platform_pci_set_power_state and that device does not have native pm support, then PCI device power state will be set to PCI_D0.
-v2: This also reverts 47e9037ac16637cd7f12b8790ea7ce6680e42168, as it's not needed after this change.
Acked-by: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by: Ajaykumar Hotchandani<ajaykumar.hotchandani@oracle.com> Signed-off-by: Yinghai Lu<yinghai.lu@oracle.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
show more ...
|
#
619a5182 |
| 12-Dec-2011 |
Rafael J. Wysocki <rjw@sisk.pl> |
PCI hotplug: Always allow acpiphp to handle non-PCIe bridges
Commit 0d52f54e2ef64c189dedc332e680b2eb4a34590a (PCI / ACPI: Make acpiphp ignore root bridges using PCIe native hotplug) added code that
PCI hotplug: Always allow acpiphp to handle non-PCIe bridges
Commit 0d52f54e2ef64c189dedc332e680b2eb4a34590a (PCI / ACPI: Make acpiphp ignore root bridges using PCIe native hotplug) added code that made the acpiphp driver completely ignore PCIe root complexes for which the kernel had been granted control of the native PCIe hotplug feature by the BIOS through _OSC. Unfortunately, however, this was a mistake, because on some systems there were PCI bridges supporting PCI (non-PCIe) hotplug under such root complexes and those bridges should have been handled by acpiphp.
For this reason, revert the changes made by the commit mentioned above and make register_slot() in drivers/pci/hotplug/acpiphp_glue.c avoid registering hotplug slots for PCIe ports that belong to root complexes with native PCIe hotplug enabled (which means that the BIOS has granted the kernel control of this feature for the given root complex). This is reported to address the original issue fixed by commit 0d52f54e2ef64c189dedc332e680b2eb4a34590a and to work on the system where that commit broke things.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
show more ...
|
Revision tags: v3.2-rc3, v3.2-rc2, v3.2-rc1 |
|
#
d90116ea |
| 06-Nov-2011 |
Rafael J. Wysocki <rjw@sisk.pl> |
PCI/ACPI: Make acpiphp ignore root bridges using SHPC native hotplug
If the kernel has requested control of the SHPC native hotplug feature for a given root bridge, the acpiphp driver should not try
PCI/ACPI: Make acpiphp ignore root bridges using SHPC native hotplug
If the kernel has requested control of the SHPC native hotplug feature for a given root bridge, the acpiphp driver should not try to handle that root bridge and it should leave it to shpchp. Failing to do so causes problems to happen if shpchp is loaded and unloaded before loading acpiphp (ACPI-based hotplug won't work in that case anyway).
To address this issue make find_root_bridges() ignore PCI root bridges with SHPC native hotplug enabled and make add_bridge() return error code if SHPC native hotplug is enabled for the given root bridge. This causes acpiphp to refuse to load if SHPC native hotplug is enabled for all root bridges and to refuse binding to the root bridges with SHPC native hotplug enabled.
Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
show more ...
|
Revision tags: v3.1 |
|
#
0d52f54e |
| 21-Oct-2011 |
Rafael J. Wysocki <rjw@sisk.pl> |
PCI / ACPI: Make acpiphp ignore root bridges using PCIe native hotplug
If the kernel has requested control of the PCIe native hotplug feature for a given root complex, the acpiphp driver should not
PCI / ACPI: Make acpiphp ignore root bridges using PCIe native hotplug
If the kernel has requested control of the PCIe native hotplug feature for a given root complex, the acpiphp driver should not try to handle that root complex and it should leave it to pciehp. Failing to do so causes problems to happen if acpiphp is loaded before pciehp on such systems.
To address this issue make find_root_bridges() ignore PCIe root complexes with PCIe native hotplug enabled and make add_bridge() return error code if PCIe native hotplug is enabled for the given root port. This causes acpiphp to refuse to load if PCIe native hotplug is enabled for all complexes and to refuse binding to the root complexes with PCIe native hotplug is enabled.
Acked-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
show more ...
|
Revision tags: v3.1-rc10, v3.1-rc9 |
|
#
6af8bef1 |
| 28-Sep-2011 |
Prarit Bhargava <prarit@redhat.com> |
PCI hotplug: acpiphp: Prevent deadlock on PCI-to-PCI bridge remove
I originally submitted a patch to workaround this by pushing all Ejection Requests and Device Checks onto the kacpi_hotplug queue.
PCI hotplug: acpiphp: Prevent deadlock on PCI-to-PCI bridge remove
I originally submitted a patch to workaround this by pushing all Ejection Requests and Device Checks onto the kacpi_hotplug queue.
http://marc.info/?l=linux-acpi&m=131678270930105&w=2
The patch is still insufficient in that Bus Checks also need to be added.
Rather than add all events, including non-PCI-hotplug events, to the hotplug queue, mjg suggested that a better approach would be to modify the acpiphp driver so only acpiphp events would be added to the kacpi_hotplug queue.
It's a longer patch, but at least we maintain the benefit of having separate queues in ACPI. This, of course, is still only a workaround the problem. As Bjorn and mjg pointed out, we have to refactor a lot of this code to do the right thing but at this point it is a better to have this code working.
The acpi core places all events on the kacpi_notify queue. When the acpiphp driver is loaded and a PCI card with a PCI-to-PCI bridge is removed the following call sequence occurs:
cleanup_p2p_bridge() -> cleanup_bridge() -> acpi_remove_notify_handler() -> acpi_os_wait_events_complete() -> flush_workqueue(kacpi_notify_wq)
which is the queue we are currently executing on and the process will hang.
Move all hotplug acpiphp events onto the kacpi_hotplug workqueue. In handle_hotplug_event_bridge() and handle_hotplug_event_func() we can simply push the rest of the work onto the kacpi_hotplug queue and then avoid the deadlock.
Signed-off-by: Prarit Bhargava <prarit@redhat.com> Cc: mjg@redhat.com Cc: bhelgaas@google.com Cc: linux-acpi@vger.kernel.org Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
show more ...
|
Revision tags: v3.1-rc8, v3.1-rc7, v3.1-rc6, v3.1-rc5, v3.1-rc4, v3.1-rc3, v3.1-rc2, v3.1-rc1, v3.0, v3.0-rc7, v3.0-rc6, v3.0-rc5 |
|
#
9c8b04be |
| 25-Jun-2011 |
Vasiliy Kulikov <segoon@openwall.com> |
ACPI: constify ops structs
Structs battery_file, acpi_dock_ops, file_operations, thermal_cooling_device_ops, thermal_zone_device_ops, kernel_param_ops are not changed in runtime. It is safe to make
ACPI: constify ops structs
Structs battery_file, acpi_dock_ops, file_operations, thermal_cooling_device_ops, thermal_zone_device_ops, kernel_param_ops are not changed in runtime. It is safe to make them const. register_hotplug_dock_device() was altered to take const "ops" argument to respect acpi_dock_ops' const notion.
Signed-off-by: Vasiliy Kulikov <segoon@openwall.com> Acked-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
show more ...
|
Revision tags: v3.0-rc4, v3.0-rc3, v3.0-rc2, v3.0-rc1, v2.6.39 |
|
#
69643e48 |
| 11-May-2011 |
Ian Campbell <ian.campbell@citrix.com> |
PCI hotplug: acpiphp: assume device is in state D0 after powering on a slot.
Devices which do not support PCI configuration space based power management may not otherwise be enabled.
Signed-off-by:
PCI hotplug: acpiphp: assume device is in state D0 after powering on a slot.
Devices which do not support PCI configuration space based power management may not otherwise be enabled.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
show more ...
|
Revision tags: v2.6.39-rc7, v2.6.39-rc6, v2.6.39-rc5, v2.6.39-rc4, v2.6.39-rc3, v2.6.39-rc2 |
|
#
25985edc |
| 30-Mar-2011 |
Lucas De Marchi <lucas.demarchi@profusion.mobi> |
Fix common misspellings
Fixes generated by 'codespell' and manually reviewed.
Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
|
Revision tags: v2.6.39-rc1, v2.6.38, v2.6.38-rc8, v2.6.38-rc7 |
|
#
47e9037a |
| 28-Feb-2011 |
Stefano Stabellini <stefano.stabellini@eu.citrix.com> |
PCI hotplug: acpiphp: set current_state to D0 in register_slot
If a device doesn't support power management (pm_cap == 0) but it is acpi_pci_power_manageable() because there is a _PS0 method declare
PCI hotplug: acpiphp: set current_state to D0 in register_slot
If a device doesn't support power management (pm_cap == 0) but it is acpi_pci_power_manageable() because there is a _PS0 method declared for it and _EJ0 is also declared for the slot then nobody is going to set current_state = PCI_D0 for this device. This is what I think it is happening:
pci_enable_device | __pci_enable_device_flags /* here we do not set current_state because !pm_cap */ | do_pci_enable_device | pci_set_power_state | __pci_start_power_transition | pci_platform_power_transition /* platform_pci_power_manageable() calls acpi_pci_power_manageable that * returns true */ | platform_pci_set_power_state /* acpi_pci_set_power_state gets called and does nothing because the * acpi device has _EJ0, see the comment "If the ACPI device has _EJ0, * ignore the device" */
at this point if we refer to the commit message that introduced the comment above (10b3dcae0f275e2546e55303d64ddbb58cec7599), it is up to the hotplug driver to set the state to D0. However AFAICT the pci hotplug driver never does, in fact drivers/pci/hotplug/acpiphp_glue.c:register_slot sets the slot flags to (SLOT_ENABLED | SLOT_POWEREDON) but it does not set the pci device current state to PCI_D0.
So my proposed fix is also to set current_state = PCI_D0 in register_slot. Comments are very welcome.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
show more ...
|
Revision tags: v2.6.38-rc6, v2.6.38-rc5, v2.6.38-rc4, v2.6.38-rc3, v2.6.38-rc2, v2.6.38-rc1, v2.6.37, v2.6.37-rc8, v2.6.37-rc7, v2.6.37-rc6, v2.6.37-rc5, v2.6.37-rc4, v2.6.37-rc3, v2.6.37-rc2, v2.6.37-rc1, v2.6.36, v2.6.36-rc8, v2.6.36-rc7, v2.6.36-rc6, v2.6.36-rc5, v2.6.36-rc4, v2.6.36-rc3, v2.6.36-rc2, v2.6.36-rc1, v2.6.35, v2.6.35-rc6, v2.6.35-rc5, v2.6.35-rc4, v2.6.35-rc3, v2.6.35-rc2, v2.6.35-rc1, v2.6.34, v2.6.34-rc7, v2.6.34-rc6, v2.6.34-rc5, v2.6.34-rc4, v2.6.34-rc3 |
|
#
5a0e3ad6 |
| 24-Mar-2010 |
Tejun Heo <tj@kernel.org> |
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being included when bu
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files.
2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files.
3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
show more ...
|
Revision tags: v2.6.34-rc2, v2.6.34-rc1 |
|
#
d0607050 |
| 24-Feb-2010 |
Shaohua Li <shaohua.li@intel.com> |
acpiphp: Execute ACPI _REG method for hotadded devices
Per ACPI spec, _ERG method should be executed before device driver gets control for hotpluged device. Firmware might do some configuration ther
acpiphp: Execute ACPI _REG method for hotadded devices
Per ACPI spec, _ERG method should be executed before device driver gets control for hotpluged device. Firmware might do some configuration there. See http://bugzilla.kernel.org/show_bug.cgi?id=10805. In this machine, _REG method of docked device will configure cardbus bridge.
Signed-off-by: Shaohua Li <shaohua.li@intel.com> Tested-by: Paul Martin <pm@debian.org> Signed-off-by: Len Brown <len.brown@intel.com>
show more ...
|
Revision tags: v2.6.33, v2.6.33-rc8, v2.6.33-rc7, v2.6.33-rc6 |
|
#
7779688f |
| 29-Jan-2010 |
Thomas Renninger <trenn@suse.de> |
ACPI: acpi_bus_{scan,bus,add}: return -ENODEV if no device was found
Callers (acpi_memhotplug.c, dock.c and others) check for the return value of acpi_bus_add() and assume a valid device was returne
ACPI: acpi_bus_{scan,bus,add}: return -ENODEV if no device was found
Callers (acpi_memhotplug.c, dock.c and others) check for the return value of acpi_bus_add() and assume a valid device was returned in case zero was returned.
Thus return -ENODEV if no device was found in acpi_bus_scan and propagate this through acpi_bus_add and acpi_bus_start.
Also remove a confusing comment in acpiphp_glue.c, acpi_bus_scan will and cannot invoke if acpi_bus_add returns no valid device.
Signed-off-by: Thomas Renninger <trenn@suse.de> Acked-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
show more ...
|
Revision tags: v2.6.33-rc5, v2.6.33-rc4, v2.6.33-rc3, v2.6.33-rc2, v2.6.33-rc1, v2.6.32, v2.6.32-rc8 |
|
#
2263576c |
| 12-Nov-2009 |
Lin Ming <ming.m.lin@intel.com> |
ACPICA: Add post-order callback to acpi_walk_namespace
The existing interface only has a pre-order callback. This change adds an additional parameter for a post-order callback which will be more use
ACPICA: Add post-order callback to acpi_walk_namespace
The existing interface only has a pre-order callback. This change adds an additional parameter for a post-order callback which will be more useful for bus scans. ACPICA BZ 779.
Also update the external calls to acpi_walk_namespace.
http://www.acpica.org/bugzilla/show_bug.cgi?id=779
Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
show more ...
|
Revision tags: v2.6.32-rc7, v2.6.32-rc6 |
|
#
58c08628 |
| 26-Oct-2009 |
Alex Chiang <achiang@hp.com> |
PCI Hotplug: acpiphp: clean up list traversals
Using list_for_each_entry instead of list_for_each allows us to enhance readability and minorly reduce some stack usage.
Signed-off-by: Alex Chiang <a
PCI Hotplug: acpiphp: clean up list traversals
Using list_for_each_entry instead of list_for_each allows us to enhance readability and minorly reduce some stack usage.
Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
show more ...
|
#
204d49a5 |
| 26-Oct-2009 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
PCI hotplug: move IOAPIC support from acpiphp to ioapic driver
This patch moves PCI I/O APIC support from acpiphp to a separate driver.
Like pciehp and shpchp, acpiphp handles PCI hotplug, i.e., ad
PCI hotplug: move IOAPIC support from acpiphp to ioapic driver
This patch moves PCI I/O APIC support from acpiphp to a separate driver.
Like pciehp and shpchp, acpiphp handles PCI hotplug, i.e., addition and removal of PCI adapters. But in addition, acpiphp handles some ACPI hotplug, such as the addition of new host bridges, and the I/O APIC support was tangled up with that.
I don't think the I/O APIC support needs to be in acpiphp; PCI I/O APICs usually appear as a function on a PCI host bridge, and we'll enumerate the APIC before any of the devices behind the bridge that use it.
As far as I know, nobody actually uses I/O APIC hotplug. It depends on acpi_register_ioapic(), which is only implemented for ia64, and I don't think any vendors have supported I/O chassis hotplug yet.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> CC: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com> CC: MUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
show more ...
|
Revision tags: v2.6.32-rc5, v2.6.32-rc4, v2.6.32-rc3, v2.6.32-rc1, v2.6.32-rc2 |
|
#
e81995bb |
| 14-Sep-2009 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
PCI hotplug: acpiphp: use generic pci_configure_slot()
Use the generic pci_configure_slot() rather than the acpiphp-specific decode_hpp() and program_hpp().
Unlike the previous acpiphp-specific cod
PCI hotplug: acpiphp: use generic pci_configure_slot()
Use the generic pci_configure_slot() rather than the acpiphp-specific decode_hpp() and program_hpp().
Unlike the previous acpiphp-specific code, pci_configure_slot() programs PCIe settings when an _HPX method provides them, so acpiphp-managed PCIe devices can now be configured.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Acked-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
show more ...
|
#
6a29172b |
| 14-Sep-2009 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
PCI hotplug: clean up acpi_get_hp_params_from_firmware() interface
This patch makes acpi_get_hp_params_from_firmware() take a pci_dev rather than a pci_bus and makes it return a standard int errno r
PCI hotplug: clean up acpi_get_hp_params_from_firmware() interface
This patch makes acpi_get_hp_params_from_firmware() take a pci_dev rather than a pci_bus and makes it return a standard int errno rather than acpi_status.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Acked-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
show more ...
|
#
fca6825a |
| 14-Sep-2009 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
PCI hotplug: acpiphp: don't cache hotplug_params in acpiphp_bridge
We always look up hotplug_params with decode_hpp() immediately before using them, so we don't need to save them in the acpiphp_brid
PCI hotplug: acpiphp: don't cache hotplug_params in acpiphp_bridge
We always look up hotplug_params with decode_hpp() immediately before using them, so we don't need to save them in the acpiphp_bridge struct. This patch follows the example of program_fw_provided_values() in pciehp_pci.c and shpchp_pci.c by just keeping the params on the stack while we need them.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Reviewed-by: Alex Chiang <achiang@hp.com> Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Acked-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
show more ...
|
#
dffb4bb5 |
| 14-Sep-2009 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
PCI hotplug: acpiphp: remove superfluous _HPP/_HPX evaluation
decode_hpp() looks up hotplug PCI parameters from ACPI and saves them in the acpiphp_bridge structure. These parameters (in bridge->hpp
PCI hotplug: acpiphp: remove superfluous _HPP/_HPX evaluation
decode_hpp() looks up hotplug PCI parameters from ACPI and saves them in the acpiphp_bridge structure. These parameters (in bridge->hpp) are only used by the acpiphp_set_hpp_values() -> program_hpp() path. In that path, we always call decode_hpp() before program_hpp(), so there's no need to do it in init_bridge_misc().
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Reviewed-by: Alex Chiang <achiang@hp.com> Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Acked-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
show more ...
|
#
7f538669 |
| 10-Sep-2009 |
Alex Chiang <achiang@hp.com> |
PCI Hotplug: convert acpi_pci_detect_ejectable() to take an acpi_handle
acpi_pci_detect_ejectable() goes through effort to convert its struct pci_bus arg to an acpi_handle, but every time we use thi
PCI Hotplug: convert acpi_pci_detect_ejectable() to take an acpi_handle
acpi_pci_detect_ejectable() goes through effort to convert its struct pci_bus arg to an acpi_handle, but every time we use this interface, we already have the handle available.
So let's just use the handle instead of converting back and forth.
Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Tested-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
show more ...
|
#
6edd7679 |
| 10-Sep-2009 |
Alex Chiang <achiang@hp.com> |
PCI Hotplug: acpiphp: find bridges the easy way
Instead of constantly evaluating _ADR and _SEG over and over again, let's simplify our lives by using:
acpi_pci_find_root() for root bridges acpi_g
PCI Hotplug: acpiphp: find bridges the easy way
Instead of constantly evaluating _ADR and _SEG over and over again, let's simplify our lives by using:
acpi_pci_find_root() for root bridges acpi_get_pci_dev() for p2p bridges
This change eliminates some copy 'n paste code and also allows us to simplify some internal interfaces.
Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Tested-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
show more ...
|
Revision tags: v2.6.31, v2.6.31-rc9, v2.6.31-rc8, v2.6.31-rc7, v2.6.31-rc6, v2.6.31-rc5 |
|
#
5228a828 |
| 23-Jul-2009 |
Alex Chiang <achiang@hp.com> |
PCI Hotplug: acpiphp: get pci_bus from acpi handle correctly
We cannot simply call acpi_get_pci_dev() on any random ACPI handle and hope that it works, because a PCI root bridge may not have an asso
PCI Hotplug: acpiphp: get pci_bus from acpi handle correctly
We cannot simply call acpi_get_pci_dev() on any random ACPI handle and hope that it works, because a PCI root bridge may not have an associated struct pci_dev.
This is allowed per the PCI specification, and is referred to as a non-materialized bridge.
So, depending on the type of PCI bridge that the handle points to, use the appropriate interface to return the struct pci_bus correctly.
Reviewed-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
show more ...
|