#
bd4674df |
| 13-Jul-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Embed function struct into struct acpiphp_context Since there has to be a struct acpiphp_func object for every struct acpiphp_context created by register_slot(), th
ACPI / hotplug / PCI: Embed function struct into struct acpiphp_context Since there has to be a struct acpiphp_func object for every struct acpiphp_context created by register_slot(), the struct acpiphp_func one can be embedded into the struct acpiphp_context one, which allows some code simplifications to be made. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
#
75a33ed1 |
| 13-Jul-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Drop flags field from struct acpiphp_bridge The only bridge flag used by the ACPI-based PCI hotplug (ACPIPHP) code is BRIDGE_HAS_EJ0, but it is only used by the eve
ACPI / hotplug / PCI: Drop flags field from struct acpiphp_bridge The only bridge flag used by the ACPI-based PCI hotplug (ACPIPHP) code is BRIDGE_HAS_EJ0, but it is only used by the event handling function hotplug_event() and if that flag is set, the corresponding function flag FUNC_HAS_EJ0 is set as well, so that bridge flag is redundant. For this reason, drop BRIDGE_HAS_EJ0 and all code referring to it and since it is the only bridge flag defined, drop the flags field from struct acpiphp_bridge entirely. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
#
7342798d |
| 13-Jul-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Drop sun field from struct acpiphp_slot If the slot unique number is passed as an additional argument to acpiphp_register_hotplug_slot(), the 'sun' field in struct
ACPI / hotplug / PCI: Drop sun field from struct acpiphp_slot If the slot unique number is passed as an additional argument to acpiphp_register_hotplug_slot(), the 'sun' field in struct acpiphp_slot is only used by ibm_[s|g]et_attention_status(), but then it's more efficient to store it in struct slot. Thus move the 'sun' field from struct acpiphp_slot to struct slot changing its data type to unsigned int in the process, and redefine acpiphp_register_hotplug_slot() to take the slot number as separate argument. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
#
bbd34fcd |
| 13-Jul-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Register all devices under the given bridge Rework register_slot() to create a struct acpiphp_func object for every function it is called for and to create acpiphp
ACPI / hotplug / PCI: Register all devices under the given bridge Rework register_slot() to create a struct acpiphp_func object for every function it is called for and to create acpiphp slots for all of them. Although acpiphp_register_hotplug_slot() is only called for the slots whose functions are identified as "ejectable", so that user space can manipulate them, the ACPIPHP notify handler, handle_hotplug_event(), is now installed for all of the registered functions (that aren't dock stations) and hotplug events may be handled for all of them. As a result, essentially, all PCI bridges represented by objects in the ACPI namespace are now going to be "hotplug" bridges and that may affect resources allocation in general, although it shouldn't lead to problems. This allows the code to be simplified substantially and addresses the problem where bus check or device check notifications for some PCI bridges or devices are not handled, because those devices are not recognized as "ejectable" or there appear to be no "ejectable" devices under those bridges. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
#
ac372338 |
| 13-Jul-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Refactor slot allocation code in register_slot() To make the code in register_slot() a bit easier to follow, change the way the slot allocation part is organized.
ACPI / hotplug / PCI: Refactor slot allocation code in register_slot() To make the code in register_slot() a bit easier to follow, change the way the slot allocation part is organized. Drop one local variable that's not used any more after that modification. This code change should not lead to any changes in behavior. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
#
f2818110 |
| 13-Jul-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Drop func field from struct acpiphp_bridge Since the func pointer in struct acpiphp_context can always be used instead of the func pointer in struct acpiphp_bridge,
ACPI / hotplug / PCI: Drop func field from struct acpiphp_bridge Since the func pointer in struct acpiphp_context can always be used instead of the func pointer in struct acpiphp_bridge, drop the latter. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
#
43e5c091 |
| 13-Jul-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Merge hotplug event handling functions There are separate handling event functions for hotplug bridges and for hotplug functions, but they may be combined into one
ACPI / hotplug / PCI: Merge hotplug event handling functions There are separate handling event functions for hotplug bridges and for hotplug functions, but they may be combined into one common hotplug event handling function which simplifies the code slightly. That also allows a theoretical bug to be dealt with which in principle may occur if a hotplug bridge is on a dock station, because in that case the bridge-specific notification should be used instead of the function-specific one, but the dock station always uses the latter. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
#
c8ebcf1f |
| 13-Jul-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Pass hotplug context objects to event handlers Modify handle_hotplug_event() to pass the entire context object (instead of its fields individually) to work function
ACPI / hotplug / PCI: Pass hotplug context objects to event handlers Modify handle_hotplug_event() to pass the entire context object (instead of its fields individually) to work functions started by it. This change makes the subsequent consolidation of the event handling work functions a bit more straightforward. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
#
ed13febf |
| 13-Jul-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Rework acpiphp_handle_to_bridge() Using the hotplug context objects introduced previously rework the ACPI-based PCI hotplug (ACPIPHP) core code to get to acpiphp_br
ACPI / hotplug / PCI: Rework acpiphp_handle_to_bridge() Using the hotplug context objects introduced previously rework the ACPI-based PCI hotplug (ACPIPHP) core code to get to acpiphp_bridge objects associated with hotplug bridges from those context objects rather than from the global list of hotplug bridges. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
#
87831273 |
| 13-Jul-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Unified notify handler for hotplug events Using the hotplug context objects introduced previously rework the ACPI-based PCI hotplug (ACPIPHP) core code so that all
ACPI / hotplug / PCI: Unified notify handler for hotplug events Using the hotplug context objects introduced previously rework the ACPI-based PCI hotplug (ACPIPHP) core code so that all notifications for ACPI device objects corresponding to the hotplug PCI devices are handled by one function, handle_hotplug_event(), which recognizes whether it has to handle a bridge or a function. In addition to code size reduction it allows some ugly pieces of code where notify handlers have to be uninstalled and installed again to go away. Moreover, it fixes a theoretically possible race between handle_hotplug_event() and free_bridge() tearing down data structures for the same handle. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
#
cb7b8ced |
| 13-Jul-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Hotplug context objects for bridges and functions When either a new hotplug bridge or a new hotplug function is added by the ACPI-based PCI hotplug (ACPIPHP) code,
ACPI / hotplug / PCI: Hotplug context objects for bridges and functions When either a new hotplug bridge or a new hotplug function is added by the ACPI-based PCI hotplug (ACPIPHP) code, attach a context object to its ACPI handle to store hotplug-related information in it. To start with, put the handle's bridge and function pointers into that object. Count references to the context objects and drop them when they are not needed any more. First of all, this makes it possible to find out if the given bridge has been registered as a function already in a much more straightforward way and acpiphp_bridge_handle_to_function() can be dropped (Yay!). This also will allow some more simplifications to be made going forward. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
#
2e862c51 |
| 13-Jul-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Always return success after adding a function When a new ACPIPHP function is added by register_slot() and the notify handler cannot be installed for it, register_sl
ACPI / hotplug / PCI: Always return success after adding a function When a new ACPIPHP function is added by register_slot() and the notify handler cannot be installed for it, register_slot() returns an error status without cleaning up, which causes the entire namespace walk in acpiphp_enumerate_slots() to be aborted, although it still may be possible to successfully install the function notify handler for other device objects under the given brigde. To address this issue make register_slot() return success after a new function has been added, even if the addition of the notify handler for it has failed. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
#
2552002a |
| 13-Jul-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Consolidate acpiphp_enumerate_slots() The acpiphp_enumerate_slots() function is now split into two parts, acpiphp_enumerate_slots() proper and init_bridge_misc() wh
ACPI / hotplug / PCI: Consolidate acpiphp_enumerate_slots() The acpiphp_enumerate_slots() function is now split into two parts, acpiphp_enumerate_slots() proper and init_bridge_misc() which is only called by the former. If these functions are combined, it is possible to make the code easier to follow and to clean up the error handling (to prevent memory leaks on error from happening in particular), so do that. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
#
be1c9de9 |
| 13-Jul-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PCI: Make bus registration and unregistration symmetric Since acpi_pci_slot_enumerate() and acpiphp_enumerate_slots() can get the ACPI device handle they need from bus->bridge, it
ACPI / PCI: Make bus registration and unregistration symmetric Since acpi_pci_slot_enumerate() and acpiphp_enumerate_slots() can get the ACPI device handle they need from bus->bridge, it is not necessary to pass that handle to them as an argument. Drop the second argument of acpi_pci_slot_enumerate() and acpiphp_enumerate_slots(), rework them to obtain the ACPI handle from bus->bridge and make acpi_pci_add_bus() and acpi_pci_remove_bus() entirely symmetrical. Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
show more ...
|
#
f09ce741 |
| 04-Jul-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / dock / PCI: Drop ACPI dock notifier chain The only user of the ACPI dock notifier chain is the ACPI-based PCI hotplug (acpiphp) driver that uses it to carry out post-dock fixups
ACPI / dock / PCI: Drop ACPI dock notifier chain The only user of the ACPI dock notifier chain is the ACPI-based PCI hotplug (acpiphp) driver that uses it to carry out post-dock fixups needed by some systems with broken _DCK. However, it is not necessary to use a separate notifier chain for that, as it can be simply replaced with a new callback in struct acpi_dock_ops. For this reason, add a new .fixup() callback to struct acpi_dock_ops and make hotplug_dock_devices() execute it for all dock devices with hotplug operations registered. Accordingly, make acpiphp point that callback to the function carrying out the post-dock fixups and do not register a separate dock notifier for each device registering dock operations. Finally, drop the ACPI dock notifier chain that has no more users. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v3.10 |
|
#
ecd046da |
| 28-Jun-2013 |
Jiang Liu <jiang.liu@huawei.com> |
ACPI: simplify acpiphp driver with new helper functions Use the new helper functions introduced previously to simplify the ACPI-based PCI hotplug (acpiphp) driver. [rjw: Changel
ACPI: simplify acpiphp driver with new helper functions Use the new helper functions introduced previously to simplify the ACPI-based PCI hotplug (acpiphp) driver. [rjw: Changelog] Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
21a31013 |
| 24-Jun-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / dock / PCI: Synchronous handling of dock events for PCI devices The interactions between the ACPI dock driver and the ACPI-based PCI hotplug (acpiphp) are currently problematic be
ACPI / dock / PCI: Synchronous handling of dock events for PCI devices The interactions between the ACPI dock driver and the ACPI-based PCI hotplug (acpiphp) are currently problematic because of ordering issues during hot-remove operations. First of all, the current ACPI glue code expects that physical devices will always be deleted before deleting the companion ACPI device objects. Otherwise, acpi_unbind_one() will fail with a warning message printed to the kernel log, for example: [ 185.026073] usb usb5: Oops, 'acpi_handle' corrupt [ 185.035150] pci 0000:1b:00.0: Oops, 'acpi_handle' corrupt [ 185.035515] pci 0000:18:02.0: Oops, 'acpi_handle' corrupt [ 180.013656] port1: Oops, 'acpi_handle' corrupt This means, in particular, that struct pci_dev objects have to be deleted before the struct acpi_device objects they are "glued" with. Now, the following happens the during the undocking of an ACPI-based dock station: 1) hotplug_dock_devices() invokes registered hotplug callbacks to destroy physical devices associated with the ACPI device objects depending on the dock station. It calls dd->ops->handler() for each of those device objects. 2) For PCI devices dd->ops->handler() points to handle_hotplug_event_func() that queues up a separate work item to execute _handle_hotplug_event_func() for the given device and returns immediately. That work item will be executed later. 3) hotplug_dock_devices() calls dock_remove_acpi_device() for each device depending on the dock station. This runs acpi_bus_trim() for each of them, which causes the underlying ACPI device object to be destroyed, but the work items queued up by handle_hotplug_event_func() haven't been started yet. 4) _handle_hotplug_event_func() queued up in step 2) are executed and cause the above failure to happen, because the PCI devices they handle do not have the companion ACPI device objects any more (those objects have been deleted in step 3). The possible breakage doesn't end here, though, because hotplug_dock_devices() may return before at least some of the _handle_hotplug_event_func() work items spawned by it have a chance to complete and then undock() will cause _DCK to be evaluated and that will cause the devices handled by the _handle_hotplug_event_func() to go away possibly while they are being accessed. This means that dd->ops->handler() for PCI devices should not point to handle_hotplug_event_func(). Instead, it should point to a function that will do the work of _handle_hotplug_event_func() synchronously. For this reason, introduce such a function, hotplug_event_func(), and modity acpiphp_dock_ops to point to it as the handler. Unfortunately, however, this is not sufficient, because if the dock code were not changed further, hotplug_event_func() would now deadlock with hotplug_dock_devices() that called it, since it would run unregister_hotplug_dock_device() which in turn would attempt to acquire the dock station's hp_lock mutex already acquired by hotplug_dock_devices(). To resolve that deadlock use the observation that unregister_hotplug_dock_device() won't need to acquire hp_lock if PCI bridges the devices on the dock station depend on are prevented from being removed prematurely while the first loop in hotplug_dock_devices() is in progress. To make that possible, introduce a mechanism by which the callers of register_hotplug_dock_device() can provide "init" and "release" routines that will be executed, respectively, during the addition and removal of the physical device object associated with the given ACPI device handle. Make acpiphp use two new functions, acpiphp_dock_init() and acpiphp_dock_release(), that call get_bridge() and put_bridge(), respectively, on the acpiphp bridge holding the given device, for this purpose. In addition to that, remove the dock station's list of "hotplug devices" and make the dock code always walk the whole list of "dependent devices" instead in such a way that the loops in hotplug_dock_devices() and dock_event() (replacing the loops over "hotplug devices") will take references to the list entries that register_hotplug_dock_device() has been called for. That prevents the "release" routines associated with those entries from being called while the given entry is being processed and for PCI devices this means that their bridges won't be removed (by a concurrent thread) while hotplug_event_func() handling them is being executed. This change is based on two earlier patches from Jiang Liu. References: https://bugzilla.kernel.org/show_bug.cgi?id=59501 Reported-and-tested-by: Alexander E. Patrakov <patrakov@gmail.com> Tracked-down-by: Jiang Liu <jiang.liu@huawei.com> Tested-by: Illya Klymov <xanf@xanf.me> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Cc: 3.9+ <stable@vger.kernel.org>
show more ...
|
#
d66ecb72 |
| 22-Jun-2013 |
Jiang Liu <jiang.liu@huawei.com> |
PCI / ACPI: Use boot-time resource allocation rules during hotplug On x86 platforms, the kernel respects PCI resource assignments from the BIOS and only reassigns resources for unassigne
PCI / ACPI: Use boot-time resource allocation rules during hotplug On x86 platforms, the kernel respects PCI resource assignments from the BIOS and only reassigns resources for unassigned BARs at boot time. However, with the ACPI-based hotplug (acpiphp), it ignores the BIOS' PCI resource assignments completely and reassigns all resources by itself. This causes differences in PCI resource allocation between boot time and runtime hotplug to occur, which is generally undesirable and sometimes actively breaks things. Namely, if there are enough resources, reassigning all PCI resources during runtime hotplug should work, but it may fail if the resources are constrained. This may happen, for instance, when some PCI devices with huge MMIO BARs are involved in the runtime hotplug operations, because the current PCI MMIO alignment algorithm may waste huge chunks of MMIO address space in those cases. On the Alexander's Sony VAIO VPCZ23A4R the BIOS allocates limited MMIO resources for the dock station which contains a device (graphics adapter) with a 256MB MMIO BAR. An attempt to reassign that during runtime hotplug causes the dock station MMIO window to be exhausted and acpiphp fails to allocate resources for the majority of devices on the dock station as a result. To prevent that from happening, modify acpiphp to follow the boot time resources allocation behavior so that the BIOS' resource assignments are respected during runtime hotplug too. [rjw: Changelog] References: https://bugzilla.kernel.org/show_bug.cgi?id=56531 Reported-and-tested-by: Alexander E. Patrakov <patrakov@gmail.com> Tested-by: Illya Klymov <xanf@xanf.me> Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Cc: 3.9+ <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v3.10-rc7, v3.10-rc6, v3.10-rc5, v3.10-rc4, v3.10-rc3, v3.10-rc2, v3.10-rc1 |
|
#
3f327e39 |
| 07-May-2013 |
Yinghai Lu <yinghai@kernel.org> |
PCI: acpiphp: Re-enumerate devices when host bridge receives Bus Check When a PCI host bridge device receives a Bus Check notification, we must re-enumerate starting with the bridge to d
PCI: acpiphp: Re-enumerate devices when host bridge receives Bus Check When a PCI host bridge device receives a Bus Check notification, we must re-enumerate starting with the bridge to discover changes (devices that have been added or removed). Prior to 668192b678 ("PCI: acpiphp: Move host bridge hotplug to pci_root.c"), this happened in _handle_hotplug_event_bridge(). After that commit, _handle_hotplug_event_bridge() is not installed for host bridges, and the host bridge notify handler, _handle_hotplug_event_root() did not re-enumerate. This patch adds re-enumeration to _handle_hotplug_event_root(). This fixes cases where we don't notice the addition or removal of PCI devices, e.g., the PCI-to-USB ExpressCard in the bugzilla below. [bhelgaas: changelog, references] Reference: https://lkml.kernel.org/r/CAAh6nkmbKR3HTqm5ommevsBwhL_u0N8Rk7Wsms_LfP=nBgKNew@mail.gmail.com Reference: https://bugzilla.kernel.org/show_bug.cgi?id=57961 Reported-by: Gavin Guo <tuffkidtt@gmail.com> Tested-by: Gavin Guo <tuffkidtt@gmail.com> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jiang Liu <jiang.liu@huawei.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> CC: stable@vger.kernel.org # v3.9+
show more ...
|
Revision tags: v3.9, v3.9-rc8, v3.9-rc7 |
|
#
3d54a316 |
| 12-Apr-2013 |
Jiang Liu <liuj97@gmail.com> |
PCI: acpiphp: Protect acpiphp data structures from concurrent updates Now acpiphp_enumerate_slots() and acpiphp_remove_slots() may be invoked concurrently by the PCI core, so add a bridg
PCI: acpiphp: Protect acpiphp data structures from concurrent updates Now acpiphp_enumerate_slots() and acpiphp_remove_slots() may be invoked concurrently by the PCI core, so add a bridge_mutex and reference count mechanism to protect acpiphp bridge/slot/function data structures. To avoid deadlock, handle_hotplug_event_bridge() will requeue the hotplug event onto the kacpi_hotplug_wq by calling alloc_acpi_hp_work(). But the workaround has introduced a minor race window because the 'bridge' passed to _handle_hotplug_event_bridge() may have already been destroyed when _handle_hotplug_event_bridge() is actually executed by the kacpi_hotplug_wq. So hold a reference count on the passed 'bridge'. Fix the same issue for handle_hotplug_event_func() too. Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Yinghai Lu <yinghai@kernel.org> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Cc: Toshi Kani <toshi.kani@hp.com>
show more ...
|
#
ad41dd9d |
| 12-Apr-2013 |
Yijing Wang <wangyijing@huawei.com> |
PCI: acpiphp: Use normal list to simplify implementation Use normal list for struct acpiphp_slot to simplify implementation. Signed-off-by: Yijing Wang <wangyijing@huawei.com> S
PCI: acpiphp: Use normal list to simplify implementation Use normal list for struct acpiphp_slot to simplify implementation. Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Yinghai Lu <yinghai@kernel.org> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Cc: Toshi Kani <toshi.kani@hp.com>
show more ...
|
#
3b63aaa7 |
| 12-Apr-2013 |
Jiang Liu <liuj97@gmail.com> |
PCI: acpiphp: Do not use ACPI PCI subdriver mechanism Previously the acpiphp driver registered itself as an ACPI PCI subdriver, so its callbacks were invoked when creating/destroying PCI
PCI: acpiphp: Do not use ACPI PCI subdriver mechanism Previously the acpiphp driver registered itself as an ACPI PCI subdriver, so its callbacks were invoked when creating/destroying PCI root buses to manage ACPI-based PCI hotplug slots. But it doesn't handle P2P bridge hotplug events, so it will cause strange behaviour if there are hotplug slots associated with a hot-removed P2P bridge. This patch fixes this issue by: 1) Directly hooking into PCI core to update hotplug slot devices when creating/destroying PCI buses through: pci_{add|remove}_bus() -> acpi_pci_{add|remove}_bus() 2) Getting rid of unused ACPI PCI subdriver-related code It also cleans up unused code in the acpiphp driver. [bhelgaas: keep acpi_pci_add_bus() stub for CONFIG_ACPI=n] Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Yinghai Lu <yinghai@kernel.org> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Cc: Toshi Kani <toshi.kani@hp.com>
show more ...
|
#
ce15d873 |
| 12-Apr-2013 |
Jiang Liu <liuj97@gmail.com> |
PCI: acpiphp: Replace local macros with standard ACPI macros Replace local defined macros (ACPI_STA_xxx) with standard ACPI macros (ACPI_STA_DEVICE_xxx). Signed-off-by: Jiang Li
PCI: acpiphp: Replace local macros with standard ACPI macros Replace local defined macros (ACPI_STA_xxx) with standard ACPI macros (ACPI_STA_DEVICE_xxx). Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Yinghai Lu <yinghai@kernel.org> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Cc: Toshi Kani <toshi.kani@hp.com>
show more ...
|
#
3a0e40be |
| 12-Apr-2013 |
Jiang Liu <liuj97@gmail.com> |
PCI: acpiphp: Remove all functions even if function 0 doesn't exist Currently function disable_device() detects slot state by checking existence of PCI function 0. It's unreliable becau
PCI: acpiphp: Remove all functions even if function 0 doesn't exist Currently function disable_device() detects slot state by checking existence of PCI function 0. It's unreliable because the PCI device for function 0 may be removed through the sysfs interface. If that happens, it will cause powering off a hotplug slot without destroying all PCI devices. On the other hand, it won't hurt us except wasting some computation power if the check is removed, because all code of disable_device() is self-protected. So remove the check. Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Yinghai Lu <yinghai@kernel.org> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Cc: Toshi Kani <toshi.kani@hp.com>
show more ...
|
#
d65eba6a |
| 12-Apr-2013 |
Yijing Wang <wangyijing@huawei.com> |
PCI: acpiphp: Use list_for_each_entry_safe() in acpiphp_sanitize_bus() Function acpiphp_sanitize_bus() may call pci_stop_and_remove_bus_device(), which in turn may remove device from bus
PCI: acpiphp: Use list_for_each_entry_safe() in acpiphp_sanitize_bus() Function acpiphp_sanitize_bus() may call pci_stop_and_remove_bus_device(), which in turn may remove device from bus->devices list. So walk the bus->devices list with list_for_each_entry_safe(). Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Yinghai Lu <yinghai@kernel.org> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Cc: Toshi Kani <toshi.kani@hp.com>
show more ...
|