1. 28 9月, 2016 2 次提交
  2. 15 9月, 2016 2 次提交
    • B
      PCI/AER: Remove aerdriver.forceload kernel parameter · 7ece1417
      Bjorn Helgaas 提交于
      Per the PCI Firmware spec, r3.0, sec 4.5.1, on ACPI systems, the OS must
      not use AER unless _OSC is present and _OSC grants AER control to the OS.
      The aerdriver.forceload kernel parameter was a way to enable Linux AER
      support on ACPI systems that lack _OSC or fail to grant control the the OS.
      
      Enabling Linux AER support when the firmware doesn't want us to is a recipe
      for problems, e.g., the firmware might be handling AER itself.
      
      Remove the aerdriver.forceload kernel parameter and related supporting
      code.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      7ece1417
    • B
      PCI/AER: Remove aerdriver.nosourceid kernel parameter · 9ff25e6b
      Bjorn Helgaas 提交于
      The aerdriver.nosourceid kernel parameter was intended for working around
      broken chipsets don't supply the source ID for AER events.  We recently
      added PCI_BUS_FLAGS_NO_AERSID, which can be set by quirks for the same
      purpose.
      
      Remove the aerdriver.nosourceid kernel parameter.  For anything other than
      debugging, asking users to find and use kernel parameters is a poor user
      experience.  Instead, we should add PCI_BUS_FLAGS_NO_AERSID quirks for any
      hardware that needs it.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      9ff25e6b
  3. 07 9月, 2016 1 次提交
  4. 26 1月, 2016 1 次提交
    • S
      PCI/AER: Flush workqueue on device remove to avoid use-after-free · 4ae2182b
      Sebastian Andrzej Siewior 提交于
      A Root Port's AER structure (rpc) contains a queue of events.  aer_irq()
      enqueues AER status information and schedules aer_isr() to dequeue and
      process it.  When we remove a device, aer_remove() waits for the queue to
      be empty, then frees the rpc struct.
      
      But aer_isr() references the rpc struct after dequeueing and possibly
      emptying the queue, which can cause a use-after-free error as in the
      following scenario with two threads, aer_isr() on the left and a
      concurrent aer_remove() on the right:
      
        Thread A                      Thread B
        --------                      --------
        aer_irq():
          rpc->prod_idx++
                                      aer_remove():
                                        wait_event(rpc->prod_idx == rpc->cons_idx)
                                        # now blocked until queue becomes empty
        aer_isr():                      # ...
          rpc->cons_idx++               # unblocked because queue is now empty
          ...                           kfree(rpc)
          mutex_unlock(&rpc->rpc_mutex)
      
      To prevent this problem, use flush_work() to wait until the last scheduled
      instance of aer_isr() has completed before freeing the rpc struct in
      aer_remove().
      
      I reproduced this use-after-free by flashing a device FPGA and
      re-enumerating the bus to find the new device.  With SLUB debug, this
      crashes with 0x6b bytes (POISON_FREE, the use-after-free magic number) in
      GPR25:
      
        pcieport 0000:00:00.0: AER: Multiple Corrected error received: id=0000
        Unable to handle kernel paging request for data at address 0x27ef9e3e
        Workqueue: events aer_isr
        GPR24: dd6aa000 6b6b6b6b 605f8378 605f8360 d99b12c0 604fc674 606b1704 d99b12c0
        NIP [602f5328] pci_walk_bus+0xd4/0x104
      
      [bhelgaas: changelog, stable tag]
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org
      4ae2182b
  5. 11 12月, 2015 1 次提交
    • B
      PCI: Check for PCI_HEADER_TYPE_BRIDGE equality, not bitmask · 93de6901
      Bjorn Helgaas 提交于
      Bit 7 of the "Header Type" register indicates a multi-function device when
      set.  Bits 0-6 contain encoded values, where 0x1 indicates a PCI-PCI
      bridge.  It is incorrect to test this as though it were a mask.
      
      For example, while the PCI 3.0 spec only defines values 0x0, 0x1, and 0x2,
      it's conceivable that a future spec could define 0x3 to mean something
      else; then tests for "(hdr_type & 0x7f) & PCI_HEADER_TYPE_BRIDGE" would
      incorrectly succeed for this new 0x3 header type.
      
      Test bits 0-6 of the Header Type for equality with PCI_HEADER_TYPE_BRIDGE.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      93de6901
  6. 17 9月, 2015 1 次提交
  7. 30 5月, 2015 1 次提交
  8. 11 6月, 2014 1 次提交
  9. 15 11月, 2013 2 次提交
    • S
      kfifo API type safety · 498d319b
      Stefani Seibold 提交于
      This patch enhances the type safety for the kfifo API.  It is now safe
      to put const data into a non const FIFO and the API will now generate a
      compiler warning when reading from the fifo where the destination
      address is pointing to a const variable.
      
      As a side effect the kfifo_put() does now expect the value of an element
      instead a pointer to the element.  This was suggested Russell King.  It
      make the handling of the kfifo_put easier since there is no need to
      create a helper variable for getting the address of a pointer or to pass
      integers of different sizes.
      
      IMHO the API break is okay, since there are currently only six users of
      kfifo_put().
      
      The code is also cleaner by kicking out the "if (0)" expressions.
      
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: NStefani Seibold <stefani@seibold.net>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Hauke Mehrtens <hauke@hauke-m.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      498d319b
    • B
      PCI: Fix whitespace, capitalization, and spelling errors · f7625980
      Bjorn Helgaas 提交于
      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: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      f7625980
  10. 15 8月, 2013 1 次提交
  11. 07 6月, 2013 1 次提交
  12. 31 5月, 2013 1 次提交
  13. 27 3月, 2013 1 次提交
  14. 14 1月, 2013 1 次提交
  15. 27 11月, 2012 1 次提交
    • V
      PCI/AER: Report success only when every device has AER-aware driver · 918b4053
      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>
      918b4053
  16. 03 11月, 2012 1 次提交
    • H
      PCI/PM: Fix deadlock when unbinding device if parent in D3cold · 90b5c1d7
      Huang Ying 提交于
      If a PCI device and its parents are put into D3cold, unbinding the
      device will trigger deadlock as follow:
      
      - driver_unbind
        - device_release_driver
          - device_lock(dev)				<--- previous lock here
          - __device_release_driver
            - pm_runtime_get_sync
              ...
                - rpm_resume(dev)
                  - rpm_resume(dev->parent)
                    ...
                      - pci_pm_runtime_resume
                        ...
                        - pci_set_power_state
                          - __pci_start_power_transition
                            - pci_wakeup_bus(dev->parent->subordinate)
                              - pci_walk_bus
                                - device_lock(dev)	<--- deadlock here
      
      
      If we do not do device_lock in pci_walk_bus, we can avoid deadlock.
      Device_lock in pci_walk_bus is introduced in commit:
      d71374da, corresponding email thread
      is: https://lkml.org/lkml/2006/5/26/38.  The patch author Zhang Yanmin
      said device_lock is added to pci_walk_bus because:
      
        Some error handling functions call pci_walk_bus. For example, PCIe
        aer. Here we lock the device, so the driver wouldn't detach from the
        device, as the cb might call driver's callback function.
      
      So I fixed the deadlock as follows:
      
      - remove device_lock from pci_walk_bus
      - add device_lock into callback if callback will call driver's callback
      
      I checked pci_walk_bus users one by one, and found only PCIe aer needs
      device lock.
      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+
      CC: Zhang Yanmin <yanmin.zhang@intel.com>
      90b5c1d7
  17. 08 9月, 2012 1 次提交
  18. 25 8月, 2012 1 次提交
  19. 24 8月, 2012 1 次提交
  20. 23 8月, 2012 1 次提交
  21. 13 1月, 2012 1 次提交
  22. 22 7月, 2011 1 次提交
    • H
      PCI: PCIe AER: add aer_recover_queue · 0918472c
      Huang Ying 提交于
      In addition to native PCIe AER, now APEI (ACPI Platform Error
      Interface) GHES (Generic Hardware Error Source) can be used to report
      PCIe AER errors too.  To add support to APEI GHES PCIe AER recovery,
      aer_recover_queue is added to export the recovery function in native
      PCIe AER driver.
      
      Recoverable PCIe AER errors are reported via NMI in APEI GHES.  Then
      APEI GHES uses irq_work to delay the error processing into an IRQ
      handler.  But PCIe AER recovery can be very time-consuming, so
      aer_recover_queue, which can be used in IRQ handler, delays the real
      recovery action into the process context, that is, work queue.
      Signed-off-by: NHuang Ying <ying.huang@intel.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      0918472c
  23. 16 10月, 2010 1 次提交
  24. 25 8月, 2010 1 次提交
    • R
      PCI: PCIe: Ask BIOS for control of all native services at once · 28eb5f27
      Rafael J. Wysocki 提交于
      After commit 852972ac (ACPI: Disable
      ASPM if the platform won't provide _OSC control for PCIe) control of
      the PCIe Capability Structure is unconditionally requested by
      acpi_pci_root_add(), which in principle may cause problems to
      happen in two ways.  First, the BIOS may refuse to give control of
      the PCIe Capability Structure if it is not asked for any of the
      _OSC features depending on it at the same time.  Second, the BIOS may
      assume that control of the _OSC features depending on the PCIe
      Capability Structure will be requested in the future and may behave
      incorrectly if that doesn't happen.  For this reason, control of
      the PCIe Capability Structure should always be requested along with
      control of any other _OSC features that may depend on it (ie. PCIe
      native PME, PCIe native hot-plug, PCIe AER).
      
      Rework the PCIe port driver so that (1) it checks which native PCIe
      port services can be enabled, according to the BIOS, and (2) it
      requests control of all these services simultaneously.  In
      particular, this causes pcie_portdrv_probe() to fail if the BIOS
      refuses to grant control of the PCIe Capability Structure, which
      means that no native PCIe port services can be enabled for the PCIe
      Root Complex the given port belongs to.  If that happens, ASPM is
      disabled to avoid problems with mishandling it by the part of the
      PCIe hierarchy for which control of the PCIe Capability Structure
      has not been received.
      
      Make it possible to override this behavior using 'pcie_ports=native'
      (use the PCIe native services regardless of the BIOS response to the
      control request), or 'pcie_ports=compat' (do not use the PCIe native
      services at all).
      
      Accordingly, rework the existing PCIe port service drivers so that
      they don't request control of the services directly.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      28eb5f27
  25. 31 7月, 2010 1 次提交
  26. 20 5月, 2010 1 次提交
  27. 12 5月, 2010 11 次提交