- 27 Jan, 2013 1 commit
-
-
Bjorn Helgaas authored
* pci/yijing-ari: PCI: shpchp: Iterate over all devices in slot, not functions 0-7 PCI: sgihp: Iterate over all devices in slot, not functions 0-7 PCI: cpcihp: Iterate over all devices in slot, not functions 0-7 PCI: pciehp: Iterate over all devices in slot, not functions 0-7 PCI: Consolidate "next-function" functions PCI: Rename pci_enable_ari() to pci_configure_ari() PCI: Enable ARI if dev and upstream bridge support it; disable otherwise
-
- 25 Jan, 2013 6 commits
-
-
Yijing Wang authored
Iterate through devices in a slot by using the upstream bridge's "bus->devices" list instead of assuming they are functions 0-7. It's possible there are several slots on the same pci_bus, so restrict it to only devices matching this slot's device number. ARI (which allows functions 0-255) is a PCIe-only feature, and this is a PCI hotplug driver, so we shouldn't find anything other than functions 0-7, but it's better to iterate the same way as other hotplug drivers. [bhelgaas: changelog, check PCI_SLOT, fix shpchp_unconfigure_device()] Signed-off-by:
Yijing Wang <wangyijing@huawei.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com>
-
Yijing Wang authored
Iterate through devices in a slot by using the upstream bridge's "bus->devices" list instead of assuming they are functions 0-7. It's possible there are several slots on the same pci_bus, so restrict it to only devices matching this slot's device number. ARI (which allows functions 0-255) is a PCIe-only feature, and this is a PCI hotplug driver, so we shouldn't find anything other than functions 0-7, but it's better to iterate the same way as other hotplug drivers. [bhelgaas: changelog, check PCI_SLOT, fix disable_slot()] Signed-off-by:
-
Yijing Wang authored
Iterate through devices in a slot by using the upstream bridge's "bus->devices" list instead of assuming they are functions 0-7. It's possible there are several slots on the same pci_bus, so restrict it to only devices matching this slot's device number. ARI (which allows functions 0-255) is a PCIe-only feature, and this is a PCI hotplug driver, so we shouldn't find anything other than functions 0-7, but it's better to iterate the same way as other hotplug drivers. [bhelgaas: changelog, check PCI_SLOT, fix cpci_unconfigure_slot()] Signed-off-by:
-
Yijing Wang authored
Currently, we enumerate devices in a slot with pci_scan_slot(), then iterate through all the devices we found by looking for functions 0-7. But that's wrong for ARI devices, which may have function numbers up to 255. This means that when we hot-add an ARI device, pciehp only initializes functions 0-7, and other functions don't work correctly. Additionally, if we hot-remove the device, pciehp only removes functions 0-7, leaving stale pci_dev structures for any other functions. This patch fixes the problem by iterating over devices in a slot by using the upstream bridge's "bus->devices" list instead. [bhelgaas: changelog] Signed-off-by:
-
Yijing Wang authored
There are several next_fn functions (no_next_fn, next_trad_fn, next_ari_fn); consolidate them in next_fn() to simplify the code. [bhelgaas: make next_fn() static, rework control flow] Signed-off-by:
Jiang Liu <jiang.liu@huawei.com> Signed-off-by:
-
Yijing Wang authored
pci_enable_ari() now supports enabling or disabling ARI forwarding. So rename pci_enable_ari() to pci_configure_ari() for easy understanding. No functional change. [bhelgaas: changelog] Signed-off-by:
-
- 24 Jan, 2013 1 commit
-
-
Yijing Wang authored
Currently, we enable ARI in a device's upstream bridge if the bridge and the device support it. But we never disable ARI, even if the device is removed and replaced with a device that doesn't support ARI. This means that if we hot-remove an ARI device and replace it with a non-ARI multi-function device, we find only function 0 of the new device because the upstream bridge still has ARI enabled, and next_ari_fn() only returns function 0 for the new non-ARI device. This patch disables ARI in the upstream bridge if the device doesn't support ARI. See the PCIe spec, r3.0, sec 6.13. [bhelgaas: changelog, function comment] Signed-off-by:
-
- 17 Jan, 2013 1 commit
-
-
Bjorn Helgaas authored
* pci/rafael-set-root-bridge-handle: ACPI / PCI: Set root bridge ACPI handle in advance
-
- 14 Jan, 2013 1 commit
-
-
Rafael J. Wysocki authored
The ACPI handles of PCI root bridges need to be known to acpi_bind_one(), so that it can create the appropriate "firmware_node" and "physical_node" files for them, but currently the way it gets to know those handles is not exactly straightforward (to put it lightly). This is how it works, roughly: 1. acpi_bus_scan() finds the handle of a PCI root bridge, creates a struct acpi_device object for it and passes that object to acpi_pci_root_add(). 2. acpi_pci_root_add() creates a struct acpi_pci_root object, populates its "device" field with its argument's address (device->handle is the ACPI handle found in step 1). 3. The struct acpi_pci_root object created in step 2 is passed to pci_acpi_scan_root() and used to get resources that are passed to pci_create_root_bus(). 4. pci_create_root_bus() creates a struct pci_host_bridge object and passes its "dev" member to device_register(). 5. platform_notify(), which for systems with ACPI is set to acpi_platform_notify(), is called. So far, so good. Now it starts to be "interesting". 6. acpi_find_bridge_device() is used to find the ACPI handle of the given device (which is the PCI root bridge) and executes acpi_pci_find_root_bridge(), among other things, for the given device object. 7. acpi_pci_find_root_bridge() uses the name (sic!) of the given device object to extract the segment and bus numbers of the PCI root bridge and passes them to acpi_get_pci_rootbridge_handle(). 8. acpi_get_pci_rootbridge_handle() browses the list of ACPI PCI root bridges and finds the one that matches the given segment and bus numbers. Its handle is then used to initialize the ACPI handle of the PCI root bridge's device object by acpi_bind_one(). However, this is *exactly* the ACPI handle we started with in step 1. Needless to say, this is quite embarassing, but it may be avoided thanks to commit f3fd0c8a (ACPI: Allow ACPI handles of devices to be initialized in advance), which makes it possible to initialize the ACPI handle of a device before passing it to device_register(). Accordingly, add a new __weak routine, pcibios_root_bridge_prepare(), defaulting to an empty implementation that can be replaced by the interested architecutres (x86 and ia64 at the moment) with functions that will set the root bridge's ACPI handle before its dev member is passed to device_register(). Make both x86 and ia64 provide such implementations of pcibios_root_bridge_prepare() and remove acpi_pci_find_root_bridge() and acpi_get_pci_rootbridge_handle() that aren't necessary any more. Included is a fix for breakage on systems with non-ACPI PCI host bridges from Bjorn Helgaas. Signed-off-by:Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
- 10 Jan, 2013 2 commits
-
-
Bjorn Helgaas authored
* pci/yinghai-survey-resources+acpi-scan: 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
-
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
-
- 09 Jan, 2013 2 commits
-
-
Bjorn Helgaas authored
* pci/yinghai-survey-resources: x86/PCI: Implement pcibios_resource_survey_bus() PCI/ACPI: Reserve firmware-allocated resources for hot-added root buses x86/PCI: Keep resource allocation functions after boot x86/PCI: Don't track firmware-assigned BAR values for hot-added devices x86/PCI: Factor out pcibios_allocate_dev_rom_resource() x86/PCI: Allocate resources on a per-bus basis for hot-adding root buses x86/PCI: Factor out pcibios_allocate_dev_resources() x86/PCI: Factor out pcibios_allocate_bridge_resources()
-
Bjorn Helgaas authored
* pci/misc: PCI: cpqphp: Cleanup and remove unreachable paths PCI: Drop "__" prefix on __pci_enable_device_flags() PCI: Use "unsigned long" for __pci_enable_device_flags to match ioport.h mn10300/PCI: Remove unused pci_root_bus frv/PCI: Remove unused pci_root_bus x86/PCI: Remove unused pci_root_bus
-
- 07 Jan, 2013 10 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 <yinghai@kernel.org> 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:
Toshi Kani <toshi.kani@hp.com>
-
Yinghai Lu authored
Thus pcibios_allocate_bus_resources() could more simple and clean. Signed-off-by:
-
Sasha Levin authored
Remove redundant checks and unreachable paths. Signed-off-by:
Sasha Levin <sasha.levin@oracle.com> Signed-off-by:
-
- 04 Jan, 2013 4 commits
-
-
Bjorn Helgaas authored
Drop the useless "__" prefix on __pci_enable_device_flags(). Signed-off-by: -
Bjorn Helgaas authored
__pci_enable_device_flags() takes values like IORESOURCE_IO and IORESOURCE_MEM, which are values for struct resource.flags, which is "unsigned long", not "resource_size_t". Signed-off-by: -
Bjorn Helgaas authored
pci_root_bus is unused, so remove all references to it. Signed-off-by: -
Bjorn Helgaas authored
pci_root_bus is unused, so remove all references to it. Signed-off-by:
-
- 03 Jan, 2013 12 commits
-
-
Bjorn Helgaas authored
pci_root_bus is unused, so remove all references to it. Signed-off-by: -
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:
-
Rafael J. Wysocki authored
The ACPI PCI root bridge driver was the only ACPI driver implementing the .start() callback, which isn't used by any ACPI drivers any more now. For this reason, acpi_start_single_object() has no purpose any more, so remove it and all references to it. Also remove acpi_bus_start_device(), whose only purpose was to call acpi_start_single_object(). Moreover, since after the removal of acpi_bus_start_device() the only purpose of acpi_bus_start() remains to call acpi_update_all_gpes(), move that into acpi_bus_add() and drop acpi_bus_start() too, remove its header from acpi_bus.h and update all of its former users accordingly. This change was previously proposed in a different from by Yinghai Lu. Signed-off-by:
-
Rafael J. Wysocki authored
Move the code from the ACPI PCI root bridge's .start() callback routine, acpi_pci_root_start(), directly into acpi_pci_root_add() and drop acpi_pci_root_start(). It is safe to do that, because it is now always guaranteed that when struct pci_dev objects are created, their companion struct acpi_device objects are already present, so it is not necessary to wait for them to be created before calling pci_bus_add_devices(). This change was previously proposed in a different form by Yinghai Lu. Signed-off-by:
-
