- 17 1月, 2013 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Commit 0090def6 (ACPI: Add interface to register/unregister device to/from power resources) made it possible to indicate to the ACPI core that if the given device depends on any power resources, then it should be resumed as soon as all of the power resources required by it to transition to the D0 power state have been turned on. Unfortunately, however, this was a mistake, because all devices depending on power resources should be treated this way (i.e. they should be resumed when all power resources required by their D0 state have been turned on) and for the majority of those devices the ACPI core can figure out by itself which (physical) devices depend on what power resources. For this reason, replace the code added by commit 0090def6 with a new, much more straightforward, mechanism that will be used internally by the ACPI core and remove all references to that code from kernel subsystems using ACPI. For the cases when there are (physical) devices that should be resumed whenever a not directly related ACPI device node goes into D0 as a result of power resources configuration changes, like in the SATA case, add two new routines, acpi_dev_pm_add_dependent() and acpi_dev_pm_remove_dependent(), allowing subsystems to manage such dependencies. Convert the SATA subsystem to use the new functions accordingly. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 15 1月, 2013 1 次提交
-
-
由 Rafael J. Wysocki 提交于
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: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NToshi Kani <toshi.kani@hp.com> Acked-by: NYinghai Lu <yinghai@kernel.org> Acked-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
-
- 03 1月, 2013 5 次提交
-
-
由 Rafael J. Wysocki 提交于
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: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NYinghai Lu <yinghai@kernel.org> Acked-by: NToshi Kani <toshi.kani@hp.com>
-
由 Rafael J. Wysocki 提交于
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: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NYinghai Lu <yinghai@kernel.org> Acked-by: NToshi Kani <toshi.kani@hp.com>
-
由 Rafael J. Wysocki 提交于
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: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NYinghai Lu <yinghai@kernel.org> Acked-by: NToshi Kani <toshi.kani@hp.com>
-
由 Rafael J. Wysocki 提交于
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: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NYinghai Lu <yinghai@kernel.org> Acked-by: NToshi Kani <toshi.kani@hp.com>
-
由 Rafael J. Wysocki 提交于
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: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NYinghai Lu <yinghai@kernel.org> Acked-by: NToshi Kani <toshi.kani@hp.com>
-
- 27 12月, 2012 3 次提交
-
-
由 Andy Lutomirski 提交于
Otherwise it fails like this on cards like the Transcend 16GB SDHC card: mmc0: new SDHC card at address b368 mmcblk0: mmc0:b368 SDC 15.0 GiB mmcblk0: error -110 sending status command, retrying mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0xb0 Tested on my Lenovo x200 laptop. [bhelgaas: changelog] Signed-off-by: NAndy Lutomirski <luto@amacapital.net> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NChris Ball <cjb@laptop.org> CC: Manoj Iyer <manoj.iyer@canonical.com> CC: stable@vger.kernel.org
-
由 Huang Ying 提交于
Ulrich reported that his USB3 cardreader does not work reliably when connected to the USB3 port. It turns out that USB3 controller failed to awaken when plugging in the USB3 cardreader. Further experiments found that the USB3 host controller can only be awakened via polling, not via PME interrupt. But if the PCIe port to which the USB3 host controller is connected is suspended, we cannot poll the controller because its config space is not accessible when the PCIe port is in a low power state. To solve the issue, the PCIe port will not be suspended if any subordinate device needs PME polling. [bhelgaas: use bool consistently rather than mixing int/bool] Reference: http://lkml.kernel.org/r/50841CCC.9030809@uli-eckhardt.deReported-by: NUlrich Eckhardt <usb@uli-eckhardt.de> Tested-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: NHuang Ying <ying.huang@intel.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> CC: stable@vger.kernel.org # v3.6+
-
由 Bjorn Helgaas 提交于
If we request "num_vfs" and the driver's sriov_configure() method enables exactly that number ("num_vfs_enabled"), we complain "Invalid value for number of VFs to enable" and return an error. We should silently return success instead. Also, use kstrtou16() since numVFs is defined to be a 16-bit field and rework to simplify control flow. Reported-by: NGreg Rose <gregory.v.rose@intel.com> Reference: http://lkml.kernel.org/r/20121214101911.00002f59@unknownSigned-off-by: NBjorn Helgaas <bhelgaas@google.com> Tested-by: NDonald Dutile <ddutile@redhat.com>
-
- 11 12月, 2012 1 次提交
-
-
由 Bjorn Helgaas 提交于
Use phys_addr_t rather than "void *" for physical memory address. This removes casts and fixes a "cast from pointer to integer of different size" warning on ppc44x_defconfig. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 08 12月, 2012 3 次提交
-
-
由 Bjorn Helgaas 提交于
Add standard #defines for ASPM fields in PCI Express Link Capability and Link Control registers. Previously we used PCIE_LINK_STATE_L0S and PCIE_LINK_STATE_L1 directly, but these are defined for the Linux ASPM interfaces, e.g., pci_disable_link_state(), and only coincidentally match the actual register bits. PCIE_LINK_STATE_CLKPM, also part of that interface, does not match the register bit. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Acked-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
-
由 Bjorn Helgaas 提交于
Use PCI Express Capability access functions to simplify portdrv. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
Use the standard #defines for PCIe Link Status and Capability registers rather than bare numbers. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 06 12月, 2012 3 次提交
-
-
由 Matthew Garrett 提交于
Platforms may provide their own mechanisms for obtaining ROMs. Add support for using data provided by the platform in that case. Signed-off-by: NMatthew Garrett <mjg@redhat.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Tested-by: NSeth Forshee <seth.forshee@canonical.com>
-
由 Matthew Garrett 提交于
Platforms may want to provide architecture-specific functionality during PCI enumeration. Add a pcibios_add_device() call that architectures can override to do so. Signed-off-by: NMatthew Garrett <mjg@redhat.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Tested-by: NSeth Forshee <seth.forshee@canonical.com>
-
由 Bjorn Helgaas 提交于
Add and use #defines for PCI-X Capability registers and fields. Note that the PCI-X Capability has a different layout for type 0 (endpoint) and type 1 (bridge) devices. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 05 12月, 2012 1 次提交
-
-
由 Huang Ying 提交于
For unbound PCI devices, what we need is: - Always in D0 state, because some devices do not work again after being put into D3 by the PCI bus. - In SUSPENDED state if allowed, so that the parent devices can still be put into low power state. To satisfy these requirements, the runtime PM for the unbound PCI devices are disabled and set to SUSPENDED state. One issue of this solution is that the PCI devices will be put into SUSPENDED state even if the SUSPENDED state is forbidden via the sysfs interface (.../power/control) of the device. This is not an issue for most devices, because most PCI devices are not used at all if unbound. But there are exceptions. For example, unbound VGA card can be used for display, but suspending its parents makes it stop working. To fix the issue, we keep the runtime PM enabled when the PCI devices are unbound. But the runtime PM callbacks will do nothing if the PCI devices are unbound. This way, we can put the PCI devices into SUSPENDED state without putting the PCI devices into D3 state. Reference: https://bugzilla.kernel.org/show_bug.cgi?id=48201Signed-off-by: NHuang Ying <ying.huang@intel.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> CC: stable@vger.kernel.org # v3.6+
-
- 01 12月, 2012 3 次提交
-
-
由 David Vrabel 提交于
Backend drivers shouldn't transition to CLOSED unless the frontend is CLOSED. If a backend does transition to CLOSED too soon then the frontend may not see the CLOSING state and will not properly shutdown. So, treat an unexpected backend CLOSED state the same as CLOSING. Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
由 Jan Glauber 提交于
Add SCLP PCI configure/deconfigure and implement a PCI hotplug controller (s390_pci_hpc). The hotplug controller creates a slot for every PCI function in stand-by or configured state. The PCI functions are named after the PCI function ID (fid). By writing to the power attribute in /sys/bus/pci/slots/<fid>/power the PCI function is moved to stand-by or configured state. If moved to the configured state the device is automatically scanned by the s390 PCI layer. Signed-off-by: NJan Glauber <jang@linux.vnet.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
由 Jan Glauber 提交于
Support PCI adapter interrupts using the Single-IRQ-mode. Single-IRQ-mode disables an adapter IRQ automatically after delivering it until the SIC instruction enables it again. This is used to reduce the number of IRQs for streaming workloads. Up to 64 MSI handlers can be registered per PCI function. A hash table is used to map interrupt numbers to MSI descriptors. The interrupt vector is scanned using the flogr instruction. Only MSI/MSI-X interrupts are supported, no legacy INTs. Signed-off-by: NJan Glauber <jang@linux.vnet.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
- 29 11月, 2012 4 次提交
-
-
由 Bill Pemberton 提交于
CONFIG_HOTPLUG is going away as an option so __devexit_p, __devint, __devinitdata, __devinitconst, and _devexit are no longer needed. Signed-off-by: NBill Pemberton <wfp5p@virginia.edu> Acked-by: NBjorn Helgaas <bhelgaas@google.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Bill Pemberton 提交于
CONFIG_HOTPLUG is being removed so setup-bus always needs to be built as part of PCI. Signed-off-by: NBill Pemberton <wfp5p@virginia.edu> Acked-by: NBjorn Helgaas <bhelgaas@google.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Bill Pemberton 提交于
With the demise of CONFIG_HOTPLUG as an option, the pci_uevent function located in hotplug.c will now always be used and doesn't need special treatment in the Makefile. Move pci_uevent into pci-driver.c and remove hotplug.c Signed-off-by: NBill Pemberton <wfp5p@virginia.edu> Acked-by: NBjorn Helgaas <bhelgaas@google.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Bill Pemberton 提交于
Remove conditional code based on CONFIG_HOTPLUG being false. It's always on now in preparation of it going away as an option. Signed-off-by: NBill Pemberton <wfp5p@virginia.edu> Acked-by: NBjorn Helgaas <bhelgaas@google.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 27 11月, 2012 1 次提交
-
-
由 Vijay Mohan Pandarathil 提交于
When an error is detected on a PCIe device which does not have an AER-aware driver, prevent AER infrastructure from reporting successful error recovery. This is because the report_error_detected() function that gets called in the first phase of recovery process allows forward progress even when the driver for the device does not have AER capabilities. It seems that all callbacks (in pci_error_handlers structure) registered by drivers that gets called during error recovery are not mandatory. So the intention of the infrastructure design seems to be to allow forward progress even when a specific callback has not been registered by a driver. However, if error handler structure itself has not been registered, it doesn't make sense to allow forward progress. As a result of the current design, in the case of a single device having an AER-unaware driver or in the case of any function in a multi-function card having an AER-unaware driver, a successful recovery is reported. Typical scenario this happens is when a PCI device is detached from a KVM host and the pci-stub driver on the host claims the device. The pci-stub driver does not have error handling capabilities but the AER infrastructure still reports that the device recovered successfully. The changes proposed here leaves the device(s)in an unrecovered state if the driver for the device or for any device in the subtree does not have error handler structure registered. This reflects the true state of the device and prevents any partial recovery (or no recovery at all) reported as successful. [bhelgaas: changelog] Signed-off-by: NVijay Mohan Pandarathil <vijaymohan.pandarathil@hp.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NLinas Vepstas <linasvepstas@gmail.com> Reviewed-by: NMyron Stowe <myron.stowe@redhat.com>
-
- 15 11月, 2012 1 次提交
-
-
由 Rafael J. Wysocki 提交于
ACPI routines for adding and removing device wakeup notifiers are currently defined in a PCI-specific file, but they will be necessary for non-PCI devices too, so move them to a separate file under drivers/acpi and rename them to indicate their ACPI origins. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 14 11月, 2012 1 次提交
-
-
由 Andrew Cooks 提交于
Config PCI_IOAPIC turned into a tristate in commit b95a7bd7, but no module license is specified. This adds the missing module license. Signed-off-by: NAndrew Cooks <acooks@gmail.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NJan Beulich <jbeulich@suse.com>
-
- 10 11月, 2012 6 次提交
-
-
由 Bjorn Helgaas 提交于
No need to check "!dev" when the caller should always supply a valid pointer. If the caller *doesn't* supply a valid pointer, it probably won't check for a failure return either. This way we'll oops and get a backtrace. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
Use the same names (almost) as the spec for TotalVFs, InitialVFs, NumVFs. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Donald Dutile 提交于
Some implementations of SRIOV provide a capability structure value of TotalVFs that is greater than what the software can support. Provide a method to reduce the capability structure reported value to the value the driver can support. This ensures sysfs reports the current capability of the system, hardware and software. Example for its use: igb & ixgbe -- report 8 & 64 as TotalVFs, but drivers only support 7 & 63 maximum. Signed-off-by: NDonald Dutile <ddutile@redhat.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Donald Dutile 提交于
Provide files under sysfs to determine the maximum number of VFs an SR-IOV-capable PCIe device supports, and methods to enable and disable the VFs on a per-device basis. Currently, VF enablement by SR-IOV-capable PCIe devices is done via driver-specific module parameters. If not setup in modprobe files, it requires admin to unload & reload PF drivers with number of desired VFs to enable. Additionally, the enablement is system wide: all devices controlled by the same driver have the same number of VFs enabled. Although the latter is probably desired, there are PCI configurations setup by system BIOS that may not enable that to occur. Two files are created for the PF of PCIe devices with SR-IOV support: sriov_totalvfs Contains the maximum number of VFs the device could support as reported by the TotalVFs register in the SR-IOV extended capability. sriov_numvfs Contains the number of VFs currently enabled on this device as reported by the NumVFs register in the SR-IOV extended capability. Writing zero to this file disables all VFs. Writing a positive number to this file enables that number of VFs. These files are readable for all SR-IOV PF devices. Writes to the sriov_numvfs file are effective only if a driver that supports the sriov_configure() method is attached. Signed-off-by: NDonald Dutile <ddutile@redhat.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Yinghai Lu 提交于
Should make pci_create_sysfs_dev_files() simpler. Also fix possible memleak in remove path. Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Yinghai Lu 提交于
Need type filled in device structure so it can be used for visible attribute control in sysfs for pci_dev. Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 08 11月, 2012 6 次提交
-
-
由 Huang Ying 提交于
There are comments on why PME poll support is necessary for PCI devices, but not for PCIe devices. That may lead to misunderstanding that PME poll is only necessary for PCI devices. So add comments related to PCIe PME poll to make it more clear. The content of comments comes from the changelog of commit: 379021d5Signed-off-by: NHuang Ying <ying.huang@intel.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Ian Abbott 提交于
The Meilhaus ME-2000i and ME-2600i data acquisition cards supported by the Comedi "me_daq" driver use the PLX PCI 9050 PCI Target bridge chip affected by the bug that prevents the chip's local configuration registers being read from BAR0 or BAR1 base addresses that are an odd multiple of 128 bytes. Use the PLX PCI 9050 quirk handler for these devices to re-allocate affected regions to a 256-byte boundary. Signed-off-by: NIan Abbott <abbotti@mev.co.uk> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Ian Abbott 提交于
The PLX PCI 9050 PCI Target bridge controller has a bug that prevents its local configuration registers being read through BAR0 (memory) or BAR1 (i/o) if the base address lies on an odd 128-byte boundary, i.e. if bit 7 of the base address is non-zero. This bug is described in the PCI 9050 errata list, version 1.4, May 2005. It was fixed in the pin-compatible PCI 9052, which can be distinguished from the PCI 9050 by checking the revision in the PCI header, which is hard-coded for these chips. Workaround the problem by re-allocating the affected regions to a 256-byte boundary. Note that BAR0 and/or BAR1 may have been disabled (size 0) during initialization of the PCI chip when its configuration is read from a serial EEPROM. Currently, the fix-up has only been used for devices with the default vendor and device ID of the PLX PCI 9050. The PCI 9052 shares the same default device ID as the PCI 9050 but they have different PCI revision codes. Signed-off-by: NIan Abbott <abbotti@mev.co.uk> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Joe Perches 提交于
dev_<level> calls take less code than dev_printk(KERN_<LEVEL> and reducing object size is good. Coalesce formats for easier grep. Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Dave Airlie 提交于
If the driver takes care of state saving, don't touch any registers on it. Optimus (dual-gpu) laptops seem to have their own form of D3cold, but unfortunately enter it on normal D3 transitions via the ACPI callback. So when we use runtime PM to transition to D3, the card disappears off the PCI bus, however we then try to access registers on it in the runtime suspend finish, which really doesn't work. This patch checks whether the pci state is saved and doesn't attempt to hit any registers after that point if it is. (Looks okay to Rafael) Signed-off-by: NDave Airlie <airlied@redhat.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Taku Izumi 提交于
pci_ext_cfg_avail() doesn't use the "struct pci_dev *" passed to it, and there's no requirement that a host bridge even be represented by a pci_dev. This drops the pci_ext_cfg_avail() parameter. [bhelgaas: changelog] Signed-off-by: NTaku Izumi <izumi.taku@jp.fujitsu.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-