Revision tags: v3.13-rc1 |
|
#
f7625980 |
| 14-Nov-2013 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Fix whitespace, capitalization, and spelling errors
Fix whitespace, capitalization, and spelling errors. No functional change. I know "busses" is not an error, but "buses" was more common, so
PCI: Fix whitespace, capitalization, and spelling errors
Fix whitespace, capitalization, and spelling errors. No functional change. I know "busses" is not an error, but "buses" was more common, so I used it consistently.
Signed-off-by: Marta Rybczynska <rybczynska@gmail.com> (pci_reset_bridge_secondary_bus()) Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
7b98118a |
| 06-Nov-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug: Consolidate deferred execution of ACPI hotplug routines
There are two different interfaces for queuing up work items on the ACPI hotplug workqueue, alloc_acpi_hp_work() used by PCI a
ACPI / hotplug: Consolidate deferred execution of ACPI hotplug routines
There are two different interfaces for queuing up work items on the ACPI hotplug workqueue, alloc_acpi_hp_work() used by PCI and PCI host bridge hotplug code and acpi_os_hotplug_execute() used by the common ACPI hotplug code and docking stations. They both are somewhat cumbersome to use and work slightly differently.
The users of alloc_acpi_hp_work() have to submit a work function that will extract the necessary data items from a struct acpi_hp_work object allocated by alloc_acpi_hp_work() and then will free that object, while it would be more straightforward to simply use a work function with one more argument and let the interface take care of the execution details.
The users of acpi_os_hotplug_execute() also have to deal with the fact that it takes only one argument in addition to the work function pointer, although acpi_os_execute_deferred() actually takes care of the allocation and freeing of memory, so it would have been able to pass more arguments to the work function if it hadn't been constrained by the connection with acpi_os_execute().
Moreover, while alloc_acpi_hp_work() makes GFP_KERNEL memory allocations, which is correct, because hotplug work items are always queued up from process context, acpi_os_hotplug_execute() uses GFP_ATOMIC, as that is needed by acpi_os_execute(). Also, acpi_os_execute_deferred() queued up by it waits for the ACPI event workqueues to flush before executing the work function, whereas alloc_acpi_hp_work() can't do anything similar. That leads to somewhat arbitrary differences in behavior between various ACPI hotplug code paths and has to be straightened up.
For this reason, replace both alloc_acpi_hp_work() and acpi_os_hotplug_execute() with a single interface, acpi_hotplug_execute(), combining their behavior and being more friendly to its users than any of the two.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
Revision tags: v3.12 |
|
#
ab122590 |
| 30-Oct-2013 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
Revert "ACPI / hotplug / PCI: Avoid doing too much for spurious notifies"
Commit 2dc4128 (ACPI / hotplug / PCI: Avoid doing too much for spurious notifies) changed the enable_slot() to check return
Revert "ACPI / hotplug / PCI: Avoid doing too much for spurious notifies"
Commit 2dc4128 (ACPI / hotplug / PCI: Avoid doing too much for spurious notifies) changed the enable_slot() to check return value of pci_scan_slot() and if it is zero return early from the function. It means that there were no new devices in this particular slot.
However, if a device appeared deeper in the hierarchy the code now ignores it causing things like Thunderbolt chaining fail to recognize new devices.
The problem with Alex Williamson's machine was solved with commit a47d8c8 (ACPI / hotplug / PCI: Avoid parent bus rescans on spurious device checks) and hence we should be able to restore the original functionality that we always rescan on bus check notification.
On a device check notification we still check what acpiphp_rescan_slot() returns and on zero bail out early.
Fixes: 2dc41281b1d1 (ACPI / hotplug / PCI: Avoid doing too much for spurious notifies) Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v3.12-rc7, v3.12-rc6, v3.12-rc5 |
|
#
fd3cfebe |
| 11-Oct-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Drop WARN_ON() from acpiphp_enumerate_slots()
The WARN_ON() in acpiphp_enumerate_slots() triggers unnecessarily for devices whose bridges are going to be handled by native PCIe
ACPI / hotplug / PCI: Drop WARN_ON() from acpiphp_enumerate_slots()
The WARN_ON() in acpiphp_enumerate_slots() triggers unnecessarily for devices whose bridges are going to be handled by native PCIe hotplug (pciehp) and the simplest way to prevent that from happening is to drop the WARN_ON().
References: https://bugzilla.kernel.org/show_bug.cgi?id=62831 Reported-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
5d449457 |
| 11-Oct-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Fix error code path in acpiphp_enumerate_slots()
One of the error code paths in acpiphp_enumerate_slots() is missing a pci_dev_put(bridge->pci_dev) call, so add it.
Signed-off
ACPI / hotplug / PCI: Fix error code path in acpiphp_enumerate_slots()
One of the error code paths in acpiphp_enumerate_slots() is missing a pci_dev_put(bridge->pci_dev) call, so add it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
show more ...
|
Revision tags: v3.12-rc4, v3.12-rc3 |
|
#
bd950799 |
| 24-Sep-2013 |
Lan Tianyu <tianyu.lan@intel.com> |
PCI: acpiphp: Convert to dynamic debug
This patch is to use pr_debug/info/warn/err to replace acpiphp debug functions and remove module's debug param.
User interface change: before this patch, boot
PCI: acpiphp: Convert to dynamic debug
This patch is to use pr_debug/info/warn/err to replace acpiphp debug functions and remove module's debug param.
User interface change: before this patch, boot with the "acpiphp.debug" kernel parameter to turn on debug. After this patch, set CONFIG_DYNAMIC_DEBUG=y and boot with "acpiphp.dyndebug=+p" instead. See Documentation/dynamic-debug-howto.txt.
[bhelgaas: changelog] Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
show more ...
|
Revision tags: v3.12-rc2, v3.12-rc1 |
|
#
a47d8c8e |
| 07-Sep-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Avoid parent bus rescans on spurious device checks
In the current ACPIPHP notify handler we always go directly for a rescan of the parent bus if we get a device check notificat
ACPI / hotplug / PCI: Avoid parent bus rescans on spurious device checks
In the current ACPIPHP notify handler we always go directly for a rescan of the parent bus if we get a device check notification for a device that is not a bridge. However, this obviously is overzealous if nothing really changes, because this way we may rescan the whole PCI hierarchy pretty much in vain.
That happens on Alex Williamson's machine whose ACPI tables contain device objects that are supposed to coresspond to PCIe root ports, but those ports aren't physically present (or at least they aren't visible in the PCI config space to us). The BIOS generates multiple device check notifies for those objects during boot and for each of them we go straight for the parent bus rescan, but the parent bus is the root bus in this particular case. In consequence, we rescan the whole PCI bus from the top several times in a row, which is completely unnecessary, increases boot time by 50% (after previous fixes) and generates excess dmesg output from the PCI subsystem.
Fix the problem by checking if we can find anything new in the slot corresponding to the device we've got a device check notify for and doing nothig if that's not the case.
The spec (ACPI 5.0, Section 5.6.6) appears to mandate this behavior, as it says:
Device Check. Used to notify OSPM that the device either appeared or disappeared. If the device has appeared, OSPM will re-enumerate from the parent. If the device has disappeared, OSPM will invalidate the state of the device. OSPM may optimize out re-enumeration.
Therefore, according to the spec, we are free to do nothing if nothing changes.
References: https://bugzilla.kernel.org/show_bug.cgi?id=60865 Reported-and-tested-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
e532e84e |
| 06-Sep-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Use _OST to notify firmware about notify status
The spec suggests that we should use _OST to notify the platform about the status of notifications it sends us, for example so t
ACPI / hotplug / PCI: Use _OST to notify firmware about notify status
The spec suggests that we should use _OST to notify the platform about the status of notifications it sends us, for example so that it doesn't repeate a notification that has been handled already.
This turns out to help reduce the amount of diagnostic output from the ACPIPHP subsystem and speed up boot on at least one system that generates multiple device check notifies for PCIe devices on the root bus during boot.
Reported-and-tested-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
2dc41281 |
| 06-Sep-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Avoid doing too much for spurious notifies
Sometimes we may get a spurious device check or bus check notify for a hotplug device and in those cases we should avoid doing all of
ACPI / hotplug / PCI: Avoid doing too much for spurious notifies
Sometimes we may get a spurious device check or bus check notify for a hotplug device and in those cases we should avoid doing all of the configuration work needed when something actually changes. To that end, check the return value of pci_scan_slot() in enable_slot() and bail out early if it is 0.
This turns out to help reduce the amount of diagnostic output from the ACPIPHP subsystem and speed up boot on at least one system that generates multiple device check notifies for PCIe devices on the root bus during boot.
Reported-and-tested-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
89ec2f2e |
| 05-Sep-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Don't trim devices before scanning the namespace
In acpiphp_bus_add() we first remove device objects corresponding to the given handle and the ACPI namespace branch below it, w
ACPI / hotplug / PCI: Don't trim devices before scanning the namespace
In acpiphp_bus_add() we first remove device objects corresponding to the given handle and the ACPI namespace branch below it, which are then re-created by acpi_bus_scan(). This used to be done to clean up after surprise removals, but now we do the cleanup through trim_stale_devices() which checks if the devices in question are actually gone before removing them, so the device hierarchy trimming in acpiphp_bus_add() is not necessary any more and, moreover, it may lead to problems if it removes device objects corresponding to devices that are actually present.
For this reason, remove the leftover acpiphp_bus_trim() from acpiphp_bus_add().
Reported-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v3.11, v3.11-rc7, v3.11-rc6 |
|
#
1aaac071 |
| 17-Aug-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Fix NULL pointer dereference in cleanup_bridge()
After commit bbd34fc (ACPI / hotplug / PCI: Register all devices under the given bridge) register_slot() is called for all PCI
ACPI / hotplug / PCI: Fix NULL pointer dereference in cleanup_bridge()
After commit bbd34fc (ACPI / hotplug / PCI: Register all devices under the given bridge) register_slot() is called for all PCI devices under a given bridge that have corresponding objects in the ACPI namespace, but it calls acpiphp_register_hotplug_slot() only for devices satisfying specific criteria. Still, cleanup_bridge() calls acpiphp_unregister_hotplug_slot() for all objects created by register_slot(), although it should only call it for the ones that acpiphp_register_hotplug_slot() has been called for (successfully). This causes a NULL pointer to be dereferenced by the acpiphp_unregister_hotplug_slot() executed by cleanup_bridge() if the object it is called for has not been passed to acpiphp_register_hotplug_slot().
To fix this problem, check if the 'slot' field of the object passed to acpiphp_unregister_hotplug_slot() in cleanup_bridge() is not NULL, which only is the case if acpiphp_register_hotplug_slot() has been executed for that object. In addition to that, make register_slot() reset the 'slot' field to NULL if acpiphp_register_hotplug_slot() has failed for the given object to prevent stale pointers from being used by acpiphp_unregister_hotplug_slot().
Reported-and-tested-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v3.11-rc5, v3.11-rc4, v3.11-rc3 |
|
#
928bea96 |
| 22-Jul-2013 |
Yinghai Lu <yinghai@kernel.org> |
PCI: Delay enabling bridges until they're needed
We currently enable PCI bridges after scanning a bus and assigning resources. This is often done in arch code.
This patch changes this so we don't
PCI: Delay enabling bridges until they're needed
We currently enable PCI bridges after scanning a bus and assigning resources. This is often done in arch code.
This patch changes this so we don't enable a bridge until necessary, i.e., until we enable a PCI device behind the bridge. We do this in the generic pci_enable_device() path, so this also removes the arch-specific code to enable bridges.
[bhelgaas: changelog] Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
show more ...
|
Revision tags: v3.11-rc2, v3.11-rc1 |
|
#
2d8b1d56 |
| 13-Jul-2013 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
ACPI / hotplug / PCI: Get rid of check_sub_bridges()
Now that acpiphp_check_bridge() always enumerates devices behind the bridge, there is no need to do that for each sub-bridge anymore like it is d
ACPI / hotplug / PCI: Get rid of check_sub_bridges()
Now that acpiphp_check_bridge() always enumerates devices behind the bridge, there is no need to do that for each sub-bridge anymore like it is done in the current ACPI-based PCI hotplug (ACPIPHP) code.
Given this we don't need check_sub_bridges() anymore, so drop that function completely.
This also simplifies the ACPIPHP code a bit.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
ff181e5a |
| 13-Jul-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Clean up bridge_mutex usage
Do not acquire bridge_mutex around the addition of a slot to its bridge's list of slots and arount the addition of a function to its slot's list of
ACPI / hotplug / PCI: Clean up bridge_mutex usage
Do not acquire bridge_mutex around the addition of a slot to its bridge's list of slots and arount the addition of a function to its slot's list of functions, because that doesn't help anything right now (those lists are walked without any locking anyway).
However, acquire bridge_mutex around the list walk in acpiphp_remove_slots() and use list_for_each_entry() there, because we terminate the walk as soon as we find the first matching entry. This prevents that list walk from colliding with bridge addition and removal.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
#
a1d0abce |
| 13-Jul-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Redefine enable_device() and disable_device()
Notice that functions enable_device() and disable_device() cannot fail and their return values are ignored in the majority of plac
ACPI / hotplug / PCI: Redefine enable_device() and disable_device()
Notice that functions enable_device() and disable_device() cannot fail and their return values are ignored in the majority of places, so redefine them as void and use the opportunity to change their names to enable_slot() and disable_slot(), respectively, which much better reflects what they do.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
#
1ad3790a |
| 13-Jul-2013 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
ACPI / hotplug / PCI: Sanitize acpiphp_get_(latch)|(adapter)_status()
There is no need for a temporary variable and all the tricks with ternary operators in acpiphp_get_(latch)|(adapter)_status(). C
ACPI / hotplug / PCI: Sanitize acpiphp_get_(latch)|(adapter)_status()
There is no need for a temporary variable and all the tricks with ternary operators in acpiphp_get_(latch)|(adapter)_status(). Change those functions to be a bit more straightforward.
[rjw: Changelog] Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
4ebe3450 |
| 16-Jul-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Check for new devices on enabled slots
The current implementation of acpiphp_check_bridge() is pretty dumb: - It enables a slot if it's not enabled and the slot status is A
ACPI / hotplug / PCI: Check for new devices on enabled slots
The current implementation of acpiphp_check_bridge() is pretty dumb: - It enables a slot if it's not enabled and the slot status is ACPI_STA_ALL. - It disables a slot if it's enabled and the slot status is not ACPI_STA_ALL.
This behavior is not sufficient to handle the Thunderbolt daisy chaining case properly, however, because in that case the bus behind the already enabled slot needs to be rescanned for new devices.
For this reason, modify acpiphp_check_bridge() so that slots are disabled and stopped if they are not in the ACPI_STA_ALL state.
For slots in the ACPI_STA_ALL state, devices behind them that don't respond are trimmed using a new function, trim_stale_devices(), introduced specifically for this purpose. That function walks the given bus and checks each device on it. If the device doesn't respond, it is assumed to be gone and is removed.
Once all of the stale devices directy behind the slot have been removed, acpiphp_check_bridge() will start looking for new devices that might have appeared on the given bus. It will do that even if the slot is already enabled (SLOT_ENABLED is set for it).
In addition to that, make the bus check notification ignore SLOT_ENABLED and go for enable_device() directly if bridge is NULL, so that devices behind the slot are re-enumerated in that case too.
This change is based on earlier patches from Kirill A Shutemov and Mika Westerberg.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
#
b91182a6 |
| 13-Jul-2013 |
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> |
ACPI / hotplug / PCI: Allow slots without new devices to be rescanned
Currently, enable_device() checks the return value of pci_scan_slot() and returns immediately if that's 0 (meaning that no new f
ACPI / hotplug / PCI: Allow slots without new devices to be rescanned
Currently, enable_device() checks the return value of pci_scan_slot() and returns immediately if that's 0 (meaning that no new functions have been found in the slot). However, if one of the functions in the slot is a bridge, some new devices may appear below it even if the bridge itself is present continuously, so it generally is necessary to do the rescan anyway just in case. [In particular, that's necessary with the Thunderbolt daisy chaining in which case new devices may be connected to the existing ones down the chain.]
The correctness of this change relies on the ability of pcibios_resource_survey_bus() to detect if it has already been called for the given bus and to skip it if so. Failure to do that will lead to resource allocation conflicts.
[rjw: Changelog] Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
55502ddb |
| 13-Jul-2013 |
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> |
ACPI / hotplug / PCI: Do not check SLOT_ENABLED in enable_device()
With Thunderbolt you can daisy chain devices: connect new devices to an already plugged one. In that case the "hotplug slot" is al
ACPI / hotplug / PCI: Do not check SLOT_ENABLED in enable_device()
With Thunderbolt you can daisy chain devices: connect new devices to an already plugged one. In that case the "hotplug slot" is already enabled, but we still want to look for new PCI devices behind it.
Reuse enable_device() to scan for new PCI devices on enabled slots and push the SLOT_ENABLED check up into acpiphp_enable_slot().
[rjw: Rebased, modified the changelog] Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
bc805a55 |
| 13-Jul-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Do not exectute _PS0 and _PS3 directly
The ACPI-based PCI hotplug (acpiphp) core code need not and really should not execute _PS0 and _PS3 directly for devices it handles.
Fir
ACPI / hotplug / PCI: Do not exectute _PS0 and _PS3 directly
The ACPI-based PCI hotplug (acpiphp) core code need not and really should not execute _PS0 and _PS3 directly for devices it handles.
First of all, it is not necessary to put devices into D3 after acpi_bus_trim() has walked through them, because acpi_device_unregister() invoked by it puts each device into D3cold before returning. Thus after disable_device() the slot should be powered down already.
Second, calling _PS0 directly on ACPI device objects may not be appropriate, because it may require power resources to be set up in a specific way in advance and that must be taken care of by the ACPI core. Thus modify acpiphp_bus_add() to power up the device using the appropriate interface after it has run acpi_bus_scan() on its handle.
After that, the functions executing _PS0 and _PS3, power_on_slot() and power_off_slot(), are not necessary any more, so drop them and update the code calling them accordingly. Also drop the function flags related to device power states, since they aren't useful any more too.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
#
5c8d0e1d |
| 13-Jul-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Do not queue up event handling work items in vain
Modify handle_hotplug_event() to avoid queing up the execution of handle_hotplug_event_work_fn() as a work item on kacpi_hotpl
ACPI / hotplug / PCI: Do not queue up event handling work items in vain
Modify handle_hotplug_event() to avoid queing up the execution of handle_hotplug_event_work_fn() as a work item on kacpi_hotplug_wq for non-hotplug events, such as ACPI_NOTIFY_DEVICE_WAKE. Move the code printing diagnostic messages for those events into handle_hotplug_event().
In addition to that, remove the bogus comment about how the core should distinguish between hotplug and non-hotplug events and queue them up on different workqueues. The core clearly cannot know in advance what events will be interesting to the given caller of acpi_install_notify_handler().
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
#
ad21d2d0 |
| 13-Jul-2013 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
ACPI / hotplug / PCI: Consolidate slot disabling and ejecting
Both acpiphp_disable_slot() and acpiphp_eject_slot() are always called together so instead of calling each separately we can consolidate
ACPI / hotplug / PCI: Consolidate slot disabling and ejecting
Both acpiphp_disable_slot() and acpiphp_eject_slot() are always called together so instead of calling each separately we can consolidate them into one function acpiphp_disable_and_eject_slot() that does both (but it will return success on _EJ0 failures that were ignored in the majority of call sites anyway).
[rjw: Rebased plus minor tweaks] Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
07bb7353 |
| 13-Jul-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Drop redundant checks from check_hotplug_bridge()
Two checks in check_hotplug_bridge() are redundant (they have been done by the caller already), so drop them.
Signed-off-by:
ACPI / hotplug / PCI: Drop redundant checks from check_hotplug_bridge()
Two checks in check_hotplug_bridge() are redundant (they have been done by the caller already), so drop them.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
#
236e2624 |
| 13-Jul-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Rework namespace scanning and trimming routines
The acpiphp_bus_trim() and acpiphp_bus_add() functions need not return error codes that are never checked, so redefine them and
ACPI / hotplug / PCI: Rework namespace scanning and trimming routines
The acpiphp_bus_trim() and acpiphp_bus_add() functions need not return error codes that are never checked, so redefine them and simplify them a bit.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
#
bda46dbb |
| 13-Jul-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Store parent in functions and bus in slots
To avoid chasing more pointers than necessary in some situations, move the bridge pointer from struct acpiphp_slot to struct acpiphp_
ACPI / hotplug / PCI: Store parent in functions and bus in slots
To avoid chasing more pointers than necessary in some situations, move the bridge pointer from struct acpiphp_slot to struct acpiphp_func (and call it 'parent') and add a bus pointer to struct acpiphp_slot.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|