- 14 11月, 2017 2 次提交
-
-
由 Bjorn Helgaas 提交于
Previously we programmed the LTR_L1.2_THRESHOLD in the parent (upstream) device using the capability pointer of the *child* (downstream) device, which corrupted some random word of the parent's config space. Use the parent's L1 SS capability pointer to program its LTR_L1.2_THRESHOLD. Fixes: aeda9ade ("PCI/ASPM: Configure L1 substate settings") Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NVidya Sagar <vidyas@nvidia.com> CC: stable@vger.kernel.org # v4.11+ CC: Rajat Jain <rajatja@google.com>
-
由 Bjorn Helgaas 提交于
Every Port that supports the L1.2 substate advertises its Port Common_Mode_Restore_Time, i.e., the time the Port requires to re-establish common mode when exiting L1.2 (see PCIe r3.1, sec 7.33.2). Per sec 5.5.3.3.1, when exiting L1.2, the Downstream Port (the device at the upstream end of the link) must send TS1 training sequences for at least T(COMMONMODE) after it detects electrical idle exit on the Link. We want this to be long enough for both ends of the Link, so we should set it to the maximum of the Port Common_Mode_Restore_Time for the upstream and downstream components on the Link. Previously we only looked at the Port Common_Mode_Restore_Time of the upstream device, so if the downstream device required more time, we didn't program the upstream device's T(COMMONMODE) correctly. Fixes: f1f0366d ("PCI/ASPM: Calculate and save the L1.2 timing parameters") Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NVidya Sagar <vidyas@nvidia.com> Acked-by: NRajat Jain <rajatja@google.com> CC: stable@vger.kernel.org # v4.11+
-
- 06 10月, 2017 1 次提交
-
-
由 Ard Biesheuvel 提交于
Even though it is unconventional, some PCIe host implementations omit the root ports entirely, and simply consist of a host bridge (which is not modeled as a device in the PCI hierarchy) and a link. When the downstream device is an endpoint, our current code does not seem to mind this unusual configuration. However, when PCIe switches are involved, the ASPM code assumes that any downstream switch port has a parent, and blindly dereferences the bus->parent->self field of the pci_dev struct to chain the downstream link state to the link state of the root port. Given that the root port is missing, the link is not modeled at all, and nor is the link state, and attempting to access it results in a NULL pointer dereference and a crash. Avoid this by allowing the link state chain to terminate at the downstream port if no root port exists. Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 14 9月, 2017 1 次提交
-
-
由 Christoph Hellwig 提交于
... and __initconst if applicable. Based on similar work for an older kernel in the Grsecurity patch. [JD: fix toshiba-wmi build] [JD: add htcpen] [JD: move __initconst where checkscript wants it] Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NJean Delvare <jdelvare@suse.de>
-
- 02 9月, 2017 1 次提交
-
-
由 Bjorn Helgaas 提交于
Fix various typos and whitespace errors: s/Synopsis/Synopsys/ s/Designware/DesignWare/ s/Keystine/Keystone/ s/gpio/GPIO/ s/pcie/PCIe/ s/phy/PHY/ s/confgiruation/configuration/ No functional change intended. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 25 8月, 2017 2 次提交
-
-
由 Dongdong Liu 提交于
Use a local "struct device *dev" for brevity and consistency in DPC driver. No functional change intended. Signed-off-by: NDongdong Liu <liudongdong3@huawei.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NKeith Busch <keith.busch@intel.com>
-
由 Dongdong Liu 提交于
Add eDPC support. Get and print the RP PIO error information when the trigger condition is RP PIO error. For more information on eDPC, please see PCI Express Base Specification Revision 3.1, section 6.2.10.3, or view the PCI-SIG eDPC ECN here: https://pcisig.com/sites/default/files/specification_documents/ECN_Enhanced_DPC_2012-11-19_final.pdfSigned-off-by: NDongdong Liu <liudongdong3@huawei.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NKeith Busch <keith.busch@intel.com>
-
- 01 8月, 2017 1 次提交
-
-
由 Christoph Hellwig 提交于
Move the error handler methods to struct pcie_port_service_driver and avoid the detour through the mostly unused pci_error_handlers structure. Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 13 7月, 2017 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Commit 76cde7e4 (PCI / PM: Make PCIe PME interrupts wake up from suspend-to-idle) went too far with preventing pcie_pme_work_fn() from clearing the root port's PME Status and re-enabling the PME interrupt which should be done for PMEs to work correctly after system resume. The failing scenario is as follows: 1. pcie_pme_suspend() finds that the PME IRQ should be designated for system wakeup, so it calls enable_irq_wake() and then sets data->suspend_level to PME_SUSPEND_WAKEUP. 2. PME interrupt happens at this point. 3. pcie_pme_irq() runs, disables the PME interrupt and queues up the execution of pcie_pme_work_fn(). 4. pcie_pme_work_fn() runs before pcie_pme_resume() and breaks out of the loop right away, because data->suspend_level is not PME_SUSPEND_NONE, and it doesn't re-enable the PME interrupt for the same reason. 5. pcie_pme_resume() runs and simply calls disable_irq_wake() without re-enabling the PME interrupt (because data->suspend_level is not PME_SUSPEND_NONE), so the PME interrupt remains disabled and the PME Status remains set. To fix this notice that there is no reason why pcie_pme_work_fn() should behave in a special way during system resume if the PME interrupt is not disabled by pcie_pme_suspend() and partially revert commit 76cde7e4 and restore the previous (and correct) behavior of pcie_pme_work_fn(). Fixes: 76cde7e4 (PCI / PM: Make PCIe PME interrupts wake up from suspend-to-idle) Reported-and-tested-by: NNaresh Solanki <naresh.solanki@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 28 6月, 2017 2 次提交
-
-
由 Rafael J. Wysocki 提交于
The run_wake flag in struct dev_pm_info is used to indicate whether or not the device is capable of generating remote wakeup signals at run time (or in the system working state), but the distinction between runtime remote wakeup and system wakeup signaling has always been rather artificial. The only practical reason for it to exist at the core level was that ACPI and PCI treated those two cases differently, but that's not the case any more after recent changes. For this reason, get rid of the run_wake flag and, when applicable, use device_set_wakeup_capable() and device_can_wakeup() instead of device_set_run_wake() and device_run_wake(), respectively. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com> Acked-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Rafael J. Wysocki 提交于
The pme_interrupt flag in struct pci_dev is set when PMEs generated by the device are going to be signaled via root port PME interrupts. Ironically enough, that information is only used by the code setting up device wakeup through ACPI which returns as soon as it sees the pme_interrupt flag set while setting up "remote runtime wakeup". That is questionable, however, because in theory there may be PCIe devices using out-of-band PME signaling under root ports handled by the native PME code or devices requiring wakeup power setup to be carried out by AML. For such devices, ACPI wakeup should be invoked regardless of whether or not native PME signaling is used in general. For this reason, drop the pme_interrupt flag and rework the code using it which then allows the ACPI-based device wakeup handling in PCI to be consolidated to use one code path for both "runtime remote wakeup" and system wakeup (from sleep states). Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com> Acked-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 17 6月, 2017 2 次提交
-
-
由 Gabriele Paoloni 提交于
Currently pcie_port_enable_irq_vec() only allocates MSI/MSI-X vectors for PME, hotplug, and AER. The Downstream Port Containment feature also supports MSI/MSI-X interrupts, so allocate a vector for it, too. Signed-off-by: NLiudongdong <liudongdong3@huawei.com> Signed-off-by: NGabriele Paoloni <gabriele.paoloni@huawei.com> [bhelgaas: changelog, comment] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NChristoph Hellwig <hch@lst.de>
-
由 Gabriele Paoloni 提交于
Root Ports can generate several different interrupts using either MSI or MSI-X, but we only support that for MSI-X. Ports that support MSI but not MSI-X are currently limited to sharing a single interrupt. Rename pcie_port_enable_msix() to pcie_port_enable_irq_vec() and extend it to support multiple interrupts using either MSI-X (preferred) or MSI. Signed-off-by: NGabriele Paoloni <gabriele.paoloni@huawei.com> [bhelgaas: changelog, reword comments, simplify PME/hotplug no-MSI logic] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NChristoph Hellwig <hch@lst.de>
-
- 23 5月, 2017 2 次提交
-
-
由 Keith Busch 提交于
This driver was OR'ing desired bits from the existing control setting. That could create an invalid DPC Trigger Enabled configuration if the platform previously set this to "ERR_FATAL", 01b. The driver currently wants to set this to ERR_NONFATAL/ERR_FATAL, 10b, and the logical OR of this gets 11b, which is reserved. Fix that by masking off the fields it is setting. Signed-off-by: NKeith Busch <keith.busch@intel.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Keith Busch 提交于
The DPC interupt may be executed on a device that is being removed. Skip queuing event handling if the status is all 1's, which should be seen only if the device is not present. Signed-off-by: NKeith Busch <keith.busch@intel.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 30 3月, 2017 1 次提交
-
-
由 Keith Busch 提交于
Add a new state to pci_dev to be set when it is unexpectedly disconnected. The PCI driver tear down functions can observe this new device state so they may skip operations that will fail. The pciehp and pcie-dpc drivers are aware when the link is down, so these set the flag when their handlers detect the device is disconnected. Tested-by: NKrishna Dhulipala <krishnad@fb.com> Signed-off-by: NKeith Busch <keith.busch@intel.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NWei Zhang <wzhang@fb.com>
-
- 08 3月, 2017 1 次提交
-
-
由 Yinghai Lu 提交于
We call pcie_aspm_exit_link_state() when we remove a device. If the device is the last PCIe function to be removed below a bridge and the bridge has an ASPM link_state struct, we disable ASPM on the link. Disabling ASPM requires link->downstream (used in pcie_config_aspm_link()). We previously set link->downstream in pcie_aspm_cap_init(), but only if the device was not blacklisted. Removing the blacklisted device caused a NULL pointer dereference in the pcie_aspm_exit_link_state() -> pcie_config_aspm_link() path: # echo 1 > /sys/bus/pci/devices/0000\:0b\:00.0/remove ... BUG: unable to handle kernel NULL pointer dereference at 0000000000000080 IP: pcie_config_aspm_link+0x5d/0x2b0 Call Trace: pcie_aspm_exit_link_state+0x75/0x130 pci_stop_bus_device+0xa4/0xb0 pci_stop_and_remove_bus_device_locked+0x1a/0x30 remove_store+0x50/0x70 dev_attr_store+0x18/0x30 sysfs_kf_write+0x44/0x60 kernfs_fop_write+0x10e/0x190 __vfs_write+0x28/0x110 ? rcu_read_lock_sched_held+0x5d/0x80 ? rcu_sync_lockdep_assert+0x2c/0x60 ? __sb_start_write+0x173/0x1a0 ? vfs_write+0xb3/0x180 vfs_write+0xc4/0x180 SyS_write+0x49/0xa0 do_syscall_64+0xa6/0x1c0 entry_SYSCALL64_slow_path+0x25/0x25 ---[ end trace bd187ee0267df5d9 ]--- To avoid this, set link->downstream in alloc_pcie_link_state(), so every pcie_link_state structure has a valid link->downstream pointer. [bhelgaas: changelog] Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NRajat Jain <rajatja@google.com> CC: stable@vger.kernel.org
-
- 15 2月, 2017 6 次提交
-
-
由 Yinghai Lu 提交于
In addition to making PME non-modular, d7def204 ("PCI/PME: Make explicitly non-modular") removed the pcie_pme_driver .remove() method, pcie_pme_remove(). pcie_pme_remove() freed the PME IRQ that was requested in pci_pme_probe(). The fact that we don't free the IRQ after d7def204 causes the following crash when removing a PCIe port device via /sys: ------------[ cut here ]------------ kernel BUG at drivers/pci/msi.c:370! invalid opcode: 0000 [#1] SMP Modules linked in: CPU: 1 PID: 14509 Comm: sh Tainted: G W 4.8.0-rc1-yh-00012-gd29438d6 RIP: 0010:[<ffffffff9758bbf5>] free_msi_irqs+0x65/0x190 ... Call Trace: [<ffffffff9758cda4>] pci_disable_msi+0x34/0x40 [<ffffffff97583817>] cleanup_service_irqs+0x27/0x30 [<ffffffff97583e9a>] pcie_port_device_remove+0x2a/0x40 [<ffffffff97584250>] pcie_portdrv_remove+0x40/0x50 [<ffffffff97576d7b>] pci_device_remove+0x4b/0xc0 [<ffffffff9785ebe6>] __device_release_driver+0xb6/0x150 [<ffffffff9785eca5>] device_release_driver+0x25/0x40 [<ffffffff975702e4>] pci_stop_bus_device+0x74/0xa0 [<ffffffff975704ea>] pci_stop_and_remove_bus_device_locked+0x1a/0x30 [<ffffffff97578810>] remove_store+0x50/0x70 [<ffffffff9785a378>] dev_attr_store+0x18/0x30 [<ffffffff97260b64>] sysfs_kf_write+0x44/0x60 [<ffffffff9725feae>] kernfs_fop_write+0x10e/0x190 [<ffffffff971e13f8>] __vfs_write+0x28/0x110 [<ffffffff970b0fa4>] ? percpu_down_read+0x44/0x80 [<ffffffff971e53a7>] ? __sb_start_write+0xa7/0xe0 [<ffffffff971e53a7>] ? __sb_start_write+0xa7/0xe0 [<ffffffff971e1f04>] vfs_write+0xc4/0x180 [<ffffffff971e3089>] SyS_write+0x49/0xa0 [<ffffffff97001a46>] do_syscall_64+0xa6/0x1b0 [<ffffffff9819201e>] entry_SYSCALL64_slow_path+0x25/0x25 ... RIP [<ffffffff9758bbf5>] free_msi_irqs+0x65/0x190 RSP <ffff89ad3085bc48> ---[ end trace f4505e1dac5b95d3 ]--- Segmentation fault Restore pcie_pme_remove(). [bhelgaas: changelog] Fixes: d7def204 ("PCI/PME: Make explicitly non-modular") Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> CC: stable@vger.kernel.org # v4.9+
-
由 Rajat Jain 提交于
Since the exit latencies for L1 substates are not advertised by a device, it is not clear in spec how to do a L1 substate exit latency check. We assume that the L1 exit latencies advertised by a device include L1 substate latencies (and hence do not do any check). If that is not true, we should do some sort of check here. (I'm not clear about what that check should like currently. I'd be glad to take up any suggestions). Signed-off-by: NRajat Jain <rajatja@google.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Rajat Jain 提交于
Configure the L1 substate settings on the upstream and downstream devices, while taking care of the rules dictated by the PCIe spec. [bhelgaas: drop "inline"] Signed-off-by: NRajat Jain <rajatja@google.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Rajat Jain 提交于
Calculate and save the timing parameters that need to be programmed if we need to enable L1.2 substates later. We use the same logic (and a constant value for 1 of the parameters) as used by Intel's coreboot: https://www.coreboot.org/pipermail/coreboot-gerrit/2015-March/021134.html https://review.coreboot.org/#/c/8832/Signed-off-by: NRajat Jain <rajatja@google.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Rajat Jain 提交于
The PCIe spec (r3.1, sec 7.33) says the L1 PM Substates Capability may be implemented only in function 0. Read the L1 substate capability structures of upstream and downstream components of the link and set it up in the device structure. [bhelgaas: add specific spec reference] Signed-off-by: NRajat Jain <rajatja@google.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Rajat Jain 提交于
Add support for ASPM L1 substates. For details about L1 substates, see the PCIe r3.1 spec, which includes the ECN below in secs 5.5 and 7.33. Add macros for the 4 new L1 substates, and add a new ASPM "POWER_SUPERSAVE" policy that can be used to enable L1 substates on a system if desired. The new policy is in a sense, a superset of the existing POWERSAVE policy. The 4 policies are now: DEFAULT: Reads and uses whatever ASPM states BIOS enabled PERFORMANCE: Everything except L0 disabled. POWERSAVE: L0s and L1 enabled (but not L1 substates) POWER_SUPERSAVE: L0s + L1 + L1 substates also enabled [bhelgaas: add PCIe r3.1 spec reference] Link: https://pcisig.com/sites/default/files/specification_documents/ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a.pdfSigned-off-by: NRajat Jain <rajatja@google.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 11 2月, 2017 3 次提交
-
-
由 Christoph Hellwig 提交于
Use pci_irq_alloc_vectors() and greatly simplify the code by managing the vector number for the subservices directly. Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Keith Busch 提交于
Per PCIe r3.1, sec 6.2.10 and sec 7.13.4, on Root Ports that support "RP Extensions for DPC", When the DPC Trigger Status bit is Set and the DPC RP Busy bit is Set, software must leave the Root Port in DPC until the DPC RP Busy bit reads 0b. Wait up to 1 second for the Root Port to become non-busy. [bhelgaas: changelog, spec references] Signed-off-by: NKeith Busch <keith.busch@intel.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Keith Busch 提交于
Decode the currently defined extended event reasons rather than just using the generic "extended" explanation. Signed-off-by: NKeith Busch <keith.busch@intel.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 28 1月, 2017 1 次提交
-
-
由 Bjorn Helgaas 提交于
In a struct pcie_link_state, link->root points to the pcie_link_state of the root of the PCIe hierarchy. For the topmost link, this points to itself (link->root = link). For others, we copy the pointer from the parent (link->root = link->parent->root). Previously we recognized that Root Ports originated PCIe hierarchies, but we treated PCI/PCI-X to PCIe Bridges as being in the middle of the hierarchy, and when we tried to copy the pointer from link->parent->root, there was no parent, and we dereferenced a NULL pointer: BUG: unable to handle kernel NULL pointer dereference at 0000000000000090 IP: [<ffffffff9e424350>] pcie_aspm_init_link_state+0x170/0x820 Recognize that PCI/PCI-X to PCIe Bridges originate PCIe hierarchies just like Root Ports do, so link->root for these devices should also point to itself. Fixes: 51ebfc92 ("PCI: Enumerate switches below PCI-to-PCIe bridges") Link: https://bugzilla.kernel.org/show_bug.cgi?id=193411 Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1022181 Tested-by: lists@ssl-mail.com Tested-by: NJayachandran C. <jnair@caviumnetworks.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v4.2+
-
- 13 12月, 2016 6 次提交
-
-
由 Bjorn Helgaas 提交于
Remove the "service driver %s loaded" and unloaded messages. All service drivers already log something in their probe functions, where they can log more useful details. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
Add a log message when we enable AER on a Root Port and the hierarchy below it. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
All other AER-related log messages use the PCI device, e.g., "pci 0000:00:1c.0", not the PCIe service device, e.g., "aer 0000:00:1c.0:pcie02". Change the probe error messages to match the rest and include a little context. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
Remove the unused DRIVER_VERSION, DRIVER_AUTHOR, and DRIVER_DESC macros. The author information is already included in a comment above. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
We already log a "Signaling PME" whenever the PME service driver claims a Root Port. In fact, we also log the same message for every device in the hierarchy below the Root Port. Log the "Signaling PME" once (only for the Root Port, since we can trivially find out which devices are below the Root Port), and include the IRQ number in the message to help connect the dots with /proc/interrupts. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Bjorn Helgaas 提交于
Since we register pcie_pme_driver only for PCI_EXP_TYPE_ROOT_PORT, the PME driver never claims Root Complex Event Collectors. Remove unused code related to Root Complex Event Collectors. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 09 12月, 2016 1 次提交
-
-
由 David Daney 提交于
Some (defective) PCIe devices are not able to reliably do link retraining. Check to see if ASPM is possible between link partners before configuring common clocking, and doing the resulting link retraining. If ASPM is not possible, there is no reason to risk losing access to a device due to an unnecessary link retraining. Signed-off-by: NDavid Daney <david.daney@cavium.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 24 11月, 2016 1 次提交
-
-
由 Johannes Thumshirn 提交于
Export pcie_find_root_port() so we can use it outside of PCIe-AER error injection. Signed-off-by: NJohannes Thumshirn <jthumshirn@suse.de> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 18 11月, 2016 2 次提交
-
-
由 Lukas Wunner 提交于
The conditions to allow runtime PM on PCIe ports are currently spread across two different files: The condition relating to hotplug ports is located in portdrv_pci.c whereas all other conditions are located in pci.c. Consolidate all conditions in a single place in pci.c, thus making it easier to follow the logic and amend conditions down the road. Note that the condition relating to hotplug ports is inserted *before* the condition relating to the "pcie_port_pm=force" command line option, so runtime PM is not afforded to hotplug ports even if this option is given. That's exactly how the code behaved up until now. If this is not desired, the ordering of the conditions can simply be reversed. No functional change intended. Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NLukas Wunner <lukas@wunner.de> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Lukas Wunner 提交于
Currently pcie_portdrv_probe() activates runtime PM on a PCIe port even if it will never actually suspend because the BIOS is too old or the "pcie_port_pm=off" option was specified on the kernel command line. A few CPU cycles can be saved by not activating runtime PM at all in these cases, because rpm_idle() and rpm_suspend() will bail out right at the beginning when calling rpm_check_suspend_allowed(), instead of carrying out various locking and assignments, invoking rpm_callback(), getting back -EBUSY and rolling everything back. The conditions checked in pci_bridge_d3_possible() are all static, they never change during uptime of the system, hence it's safe to call this to determine if runtime PM should be activated. No functional change intended. Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NLukas Wunner <lukas@wunner.de> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 15 11月, 2016 1 次提交
-
-
由 Julia Lawall 提交于
Use DEVICE_ATTR_RW for read-write attributes. This simplifies the source code, improves readability, and reduces the chance of inconsistencies. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // <smpl> @rw@ declarer name DEVICE_ATTR; identifier x,x_show,x_store; @@ DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\), x_show, x_store); @script:ocaml@ x << rw.x; x_show << rw.x_show; x_store << rw.x_store; @@ if not (x^"_show" = x_show && x^"_store" = x_store) then Coccilib.include_match false @@ declarer name DEVICE_ATTR_RW; identifier rw.x,rw.x_show,rw.x_store; @@ - DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\), x_show, x_store); + DEVICE_ATTR_RW(x); // </smpl> Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 30 9月, 2016 1 次提交
-
-
由 Cao jin 提交于
0516c8bc ("PCI: PCIe portdrv: Simplily probe callback of service drivers") removed the "id" argument of aer_probe() but neglected to remove the kernel-doc comment. Update the comment. [bhelgaas: changelog] Signed-off-by: NCao jin <caoj.fnst@cn.fujitsu.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 28 9月, 2016 1 次提交
-
-
由 Keith Busch 提交于
Save the position of the error reporting capability so it doesn't need to be rediscovered during error handling. Signed-off-by: NKeith Busch <keith.busch@intel.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> CC: Lukas Wunner <lukas@wunner.de>
-