- 25 Jan, 2013 12 commits
-
-
Yinghai Lu authored
We want to put pci_dev structs in the device tree as soon as possible so for_each_pci_dev() iteration will not miss them, but driver attachment needs to be delayed until after pci_assign_unassigned_resources() to make sure all devices have resources assigned first. This patch moves device registering from pci_bus_add_devices() to pci_device_add(), which happens earlier, leaving driver attachment in pci_bus_add_devices(). It also removes unattached child bus handling in pci_bus_add_devices(). That's not needed because child bus via pci_add_new_bus() is already in parent bus children list. [bhelgaas: changelog] Signed-off-by:
Yinghai Lu <yinghai@kernel.org> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Yinghai Lu authored
We want to add PCI devices to the device tree as early as possible but delay attaching drivers. device_add() adds a device to the device hierarchy and (via device_attach()) attaches a matching driver and calls its .probe() method. We want to separate adding the device to the hierarchy from attaching the driver. This patch does that by adding "match_driver" in struct pci_dev. When false, we return failure from pci_bus_match(), which makes device_attach() believe there's no matching driver. Later, we set "match_driver = true" and call device_attach() again, which now attaches the driver and calls its .probe() method. [bhelgaas: changelog, explicitly init dev->match_driver, fold device_attach() call into pci_bus_add_device()] Signed-off-by:
-
Yinghai Lu authored
Could have root bus hot-added later and there may be slots that need acpiphp. The result returned by acpiphp_get_num_slots() is meaningless, because the bridge the slots are under may be added after this function has been called, so drop acpiphp_get_num_slots() and the code using it. Signed-off-by:
-
Tang Chen authored
acpi_install_notify_handler() could fail. So check the exit status and give a better debug info. Signed-off-by:
Tang Chen <tangchen@cn.fujitsu.com> Signed-off-by:
-
Yinghai Lu authored
The acpiphp driver is confusing because it contains partial support for PCI host bridge hotplug as well as support for hotplug of PCI devices. This patch moves the host bridge hot-add support to pci_root.c and adds hot-remove support in pci_root.c. How to test it: if sci_emu patch is applied, find out root bus number to ACPI root name mapping from dmesg or /sys. To remove root bus: echo "\_SB.PCIB 3" > /sys/kernel/debug/acpi/sci_notify To add back root bus: echo "\_SB.PCIB 1" > /sys/kernel/debug/acpi/sci_notify Signed-off-by:
-
Yinghai Lu authored
Will need to use it for PCI root bridge hotplug support, so rename *acpiphp* to *acpi* and move to osc.c. Also make kacpi_hotplug_wq static after that. Signed-off-by:
-
Jiang Liu authored
According to device model documentation, the way to create/destroy PCI devices should be symmetric. The rule is to either use 1) device_register()/device_unregister() or 2) device_initialize()/device_add()/device_del()/put_device(). So change PCI core logic to follow the rule and get rid of the redundant pci_dev_get()/pci_dev_put() pair. Signed-off-by:
Jiang Liu <jiang.liu@huawei.com> Signed-off-by:
-
Jiang Liu authored
Function pci_get_dev_by_id() takes a reference on the pci_dev returned, so pci_dev_present() should release the corresponding reference. Signed-off-by:
-
Yinghai Lu authored
Otherwise irq_desc for PCI bridge with hot-added IOAPIC may not be allocated on the local node. Signed-off-by:
-
Yinghai Lu authored
We can stop trying according to try_number now and do not need to use root_bus checking as stop sign. In extreme case we could need to reallocate resource for device just under root bus. For PCI root bus hot-add, we need to retry to assign resources to PCI devices just under pci root bus. Signed-off-by:
-
Yinghai Lu authored
When system support hotplug bridge with children hotplug slots, we need to make sure that parent bridge get preallocated resource so later when device is plugged into children slot, those children devices will get resource allocated. We do not meet this problem, because for PCIe hotplug card, when acpiphp is used, pci_scan_bridge will set that for us when detect hotplug bit in slot cap. Reported-and-tested-by:
Jason Baron <jbaron@redhat.com> Signed-off-by:
-
Bjorn Helgaas authored
Merge branch 'acpi-scan' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm into pci/acpi-scan2 * 'acpi-scan' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI / scan: Drop acpi_bus_add() and use acpi_bus_scan() instead ACPI: update ej_event interface to take acpi_device ACPI / scan: Add second pass to acpi_bus_trim() ACPI / scan: Change the implementation of acpi_bus_trim() ACPI / scan: Drop the second argument of acpi_bus_trim() ACPI / scan: Drop the second argument of acpi_device_unregister() ACPI: Remove the ops field from struct acpi_device ACPI: remove unused acpi_op_bind and acpi_op_unbind ACPI / scan: Fix check of device_attach() return value.
-
- 19 Jan, 2013 1 commit
-
-
Rafael J. Wysocki authored
The only difference between acpi_bus_scan() and acpi_bus_add() is the invocation of acpi_update_all_gpes() in the latter which in fact is unnecessary, because acpi_update_all_gpes() has already been called by acpi_scan_init() and the way it is implemented guarantees the next invocations of it to do nothing. For this reason, drop acpi_bus_add() and make all its callers use acpi_bus_scan() directly instead of it. Additionally, rearrange the code in acpi_scan_init() slightly to improve the visibility of the acpi_update_all_gpes() call in there. Signed-off-by:
-
- 15 Jan, 2013 6 commits
-
-
Yinghai Lu authored
Should use acpi_device pointer directly instead of use handle and get the device pointer again later. Signed-off-by:
-
Rafael J. Wysocki authored
Make acpi_bus_trim() work in analogy with acpi_bus_scan() and carry out two passes such that ACPI drivers will be detached from device nodes being removed in the first pass and the device nodes themselves will be removed in the second pass. For this purpose split the driver unregistration out of acpi_bus_remove() into a new routine, acpi_bus_device_detach(), that will be executed by acpi_bus_trim() in the additional first pass as a post-order callback. This is necessary, because some ACPI drivers' .remove() routines unregister struct device objects associated with the ACPI device nodes being removed and that needs to happen while the ACPI device nodes are still around (for example, in case they need to be used for power management or similar things at that time). Signed-off-by:
Toshi Kani <toshi.kani@hp.com> Acked-by:
Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
-
Rafael J. Wysocki authored
The current acpi_bus_trim() implementation is not really straightforward and may be simplified significantly by using acpi_walk_namespace() with acpi_bus_remove() as a post-order callback. Observe that acpi_bus_remove(), as called by acpi_bus_trim(), cannot actually fail, because its first argument is guaranteed not to be NULL thanks to the acpi_bus_get_device() check in acpi_bus_trim(), so simply move the acpi_bus_get_device() check to acpi_bus_remove() and use acpi_walk_namespace() to execute it for every device under start->handle as a post-order callback. The, run it directly for start->handle itself. Signed-off-by:
-
Rafael J. Wysocki authored
All callers of acpi_bus_trim() pass 1 (true) as the second argument of it, so remove that argument entirely and change acpi_bus_trim() to always behave as though it were 1. Signed-off-by:
-
Rafael J. Wysocki authored
Drop the second argument of acpi_device_unregister(), type, which is not used by that function. Signed-off-by:
-
Rafael J. Wysocki authored
The ops field in struct acpi_device is not used anywhere, so remove it. Signed-off-by:
-
- 14 Jan, 2013 1 commit
-
-
Jiang Liu authored
With commit f2a33cde55a03 "ACPI: Drop ACPI device .bind() and .unbind() callbacks", acpi_op_bind and acpi_op_unbind are not used any more. So remove them. Signed-off-by:
-
- 11 Jan, 2013 1 commit
-
-
Mika Westerberg authored
Since device_attach() returns 1 on success (a driver has been bound to the device), the check against its return value in acpi_bus_device_attach() should modified to take that into accout. Make it so. [rjw: Subject and changelog.] Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
-
- 10 Jan, 2013 1 commit
-
-
Bjorn Helgaas authored
Merge branch 'acpi-scan' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm into pci/yinghai-survey-resources+acpi-scan * 'acpi-scan' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI / scan: Treat power resources in a special way ACPI: Remove unused struct acpi_pci_root.id member ACPI: Drop ACPI device .bind() and .unbind() callbacks ACPI / PCI: Move the _PRT setup and cleanup code to pci-acpi.c ACPI / PCI: Rework the setup and cleanup of device wakeup ACPI: Add .setup() and .cleanup() callbacks to struct acpi_bus_type ACPI: Make acpi_bus_scan() and acpi_bus_add() take only one argument ACPI: Replace ACPI device add_type field with a match_driver flag ACPI: Drop the second argument of acpi_bus_scan() ACPI: Remove the arguments of acpi_bus_add() that are not used ACPI: Remove acpi_start_single_object() and acpi_bus_start() ACPI / PCI: Fold acpi_pci_root_start() into acpi_pci_root_add() ACPI: Change the ordering of acpi_bus_check_add() ACPI: Replace struct acpi_bus_ops with enum type ACPI: Reduce the usage of struct acpi_bus_ops ACPI: Make acpi_bus_add() and acpi_bus_start() visibly different ACPI: Change the ordering of PCI root bridge driver registrarion ACPI: Separate adding ACPI device objects from probing ACPI drivers Conflicts: drivers/acpi/pci_root.c
-
- 07 Jan, 2013 9 commits
-
-
Yinghai Lu authored
During testing remove/rescan root bus 00, found [ 338.142574] bus: 'pci': really_probe: probing driver ata_piix with device 0000:00:01.1 [ 338.146788] ata_piix 0000:00:01.1: device not available (can't reserve [io 0x01f0-0x01f7]) [ 338.150565] ata_piix: probe of 0000:00:01.1 failed with error -22 because that fixed resource is not claimed. For bootint path it is claimed in from arch/x86/pci/i386.c::pcibios_allocate_resources() Claim those resources, so on the remove/rescan will still use old resources. It is some kind honoring FW setting in the registers during hot add. esp root-bus hot add is through acpi, BIOS has chance to set some registers before handing over. [bhelgaas: move weak definition to patch that uses it] Signed-off-by: -
Yinghai Lu authored
Firmware may have assigned PCI BARs for hot-added devices, so reserve those resources before trying to allocate more. [bhelgaas: move empty weak definition here] Signed-off-by:
-
Yinghai Lu authored
The PCI resource allocation functions will be used for hot-added devices, so keep them around. [bhelgaas: changelog] Signed-off-by:
-
Yinghai Lu authored
The BIOS doesn't assign BAR values for hot-added devices, so don't bother saving the original values when we enumerate these devices. [bhelgaas: changelog, return constant 0 in pcibios_retrieve_fw_addr] Signed-off-by:
-
Yinghai Lu authored
Factor pcibios_allocate_rom_resources() and pcibios_allocate_dev_rom_resource() out of pcibios_assign_resources(). This will allow us to allocate ROM resources for hot-added root buses. [bhelgaas: changelog] Signed-off-by:
-
Yinghai Lu authored
Previously pcibios_allocate_resources() allocated resources at boot-time for all PCI devices using for_each_pci_dev(). This patch changes pcibios_allocate_resources() so we can specify a bus, so we can do similar allocation when hot-adding a root bus. [bhelgaas: changelog] Signed-off-by:
-
Yinghai Lu authored
Factor pcibios_allocate_dev_resources() out of pcibios_allocate_resources(). Currently we only allocate these resources at boot-time with a for_each_pci_dev() loop. Eventually we'll use pcibios_allocate_dev_resources() for hot-added devices, too. [bhelgaas: changelog] Signed-off-by:
-
Rafael J. Wysocki authored
Commit 805d410 (ACPI: Separate adding ACPI device objects from probing ACPI drivers) introduced an ACPI power resources management regression, because it didn't ensure that the power resources driver bind to the struct acpi_device objects corresponding to power resources as soon as they were created. As a result, ACPI power management routines may attempt to access power resource objects before they are ready to use. To fix this problem, tell the acpi_add_single_object() in acpi_bus_check_add() to probe the driver for objects of type ACPI_BUS_TYPE_POWER. This fix has been verified to work on HP nx6325 where the problem was first observed. Signed-off-by:
-
Yinghai Lu authored
Thus pcibios_allocate_bus_resources() could more simple and clean. Signed-off-by:
-
- 03 Jan, 2013 9 commits
-
-
Bjorn Helgaas authored
This member is never initialized and never referenced, so remove it. Signed-off-by:
-
Rafael J. Wysocki authored
Drop the .bind() and .unbind() that have no more users from struct acpi_device_ops and remove all of the code referring to them from drivers/acpi/scan.c. Signed-off-by:
-
Rafael J. Wysocki authored
Move the code related to _PRT setup and removal and to power resources from acpi_pci_bind() and acpi_pci_unbind() to the .setup() and .cleanup() callbacks in acpi_pci_bus and remove acpi_pci_bind() and acpi_pci_unbind() that have no purpose any more. Accordingly, remove the code related to device .bind() and .unbind() operations from the ACPI PCI root bridge driver. Signed-off-by:
-
Rafael J. Wysocki authored
Currently, the ACPI wakeup capability of PCI devices is set up in two different places, partially in acpi_pci_bind() where runtime wakeup is initialized and partially in platform_pci_wakeup_init(), where system wakeup is initialized. The cleanup is only done in acpi_pci_unbind() and it only covers runtime wakeup. Use the new .setup() and .cleanup() callbacks in struct acpi_bus_type to consolidate that code and do the setup and the cleanup each in one place. Signed-off-by:
-
Rafael J. Wysocki authored
Add two new callbacks,.setup() and .cleanup(), struct acpi_bus_type and modify acpi_platform_notify() to call .setup() after executing acpi_bind_one() successfully and acpi_platform_notify_remove() to call .cleanup() before running acpi_unbind_one(). This will allow the users of struct acpi_bus_type, PCI in particular, to specify operations to be executed right after the given device has been associated with a companion struct acpi_device and right before it's going to be detached from that companion, respectively. The main motivation is to be able to get rid of acpi_pci_bind() and acpi_pci_unbind(), which are horrible horrible stuff. [In short, there are three problems with them: The way they populate the .bind() and .unbind() callbacks of ACPI devices is rather less than straightforward, they require special hotplug-specific paths to be present in the ACPI namespace scanning code and by the time acpi_pci_unbind() is called the PCI device object in question may not exist any more.] Signed-off-by:
-
Rafael J. Wysocki authored
The callers of acpi_bus_add() usually assume that if it has succeeded, then a struct acpi_device object has been attached to the handle passed as the first argument. Unfortunately, however, this assumption is wrong, because acpi_bus_scan(), and acpi_bus_add() too as a result, may return a pointer to a different struct acpi_device object on success (it may be an object corresponding to one of the descendant ACPI nodes in the namespace scope below that handle). For this reason, the callers of acpi_bus_add() who care about whether or not a struct acpi_device object has been created for its first argument need to check that using acpi_bus_get_device() anyway, so the second argument of acpi_bus_add() is not really useful for them. The same observation applies to acpi_bus_scan() executed directly from acpi_scan_init(). Therefore modify the relevant callers of acpi_bus_add() to check the existence of the struct acpi_device in question with the help of acpi_bus_get_device() and drop the no longer necessary second argument of acpi_bus_add(). Accordingly, modify acpi_scan_init() to use acpi_bus_get_device() to get acpi_root and drop the no longer needed second argument of acpi_bus_scan(). Signed-off-by:
-
Rafael J. Wysocki authored
After the removal of the second argument of acpi_bus_scan() there is no difference between the ACPI_BUS_ADD_MATCH and ACPI_BUS_ADD_START add types, so the add_type field in struct acpi_device may be replaced with a single flag. Do that calling the flag match_driver. Signed-off-by:
-
Rafael J. Wysocki authored
After the removal of acpi_start_single_object() and acpi_bus_start() the second argument of acpi_bus_scan() is not necessary any more, so drop it and update acpi_bus_check_add() accordingly. Signed-off-by:
-
Rafael J. Wysocki authored
Notice that acpi_bus_add() uses only 2 of its 4 arguments and redefine its header to match the body. Update all of its callers as necessary and observe that this leads to quite a number of removed lines of code (Linus will like that). Add a kerneldoc comment documenting acpi_bus_add() and wonder how its callers make wrong assumptions about the second argument (make note to self to take care of that later). Signed-off-by:
-
