An error occurred fetching the project authors.
  1. 30 Sep, 2015 1 commit
    • Bjorn Helgaas's avatar
      PCI: Fix TI816X class code quirk · 8c9777e5
      Bjorn Helgaas authored
      commit d1541dc9 upstream.
      
      In fixup_ti816x_class(), we assigned "class = PCI_CLASS_MULTIMEDIA_VIDEO".
      But PCI_CLASS_MULTIMEDIA_VIDEO is only the two-byte base class/sub-class
      and needs to be shifted to make space for the low-order interface byte.
      
      Shift PCI_CLASS_MULTIMEDIA_VIDEO to set the correct class code.
      
      Fixes: 63c44080 ("PCI: Add quirk for setting valid class for TI816X Endpoint")
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: Hemant Pedanekar <hemantp@ti.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      8c9777e5
  2. 18 Sep, 2015 1 commit
  3. 31 Oct, 2014 1 commit
  4. 17 Jul, 2014 1 commit
  5. 12 Aug, 2013 2 commits
  6. 25 Jul, 2013 1 commit
  7. 18 Jun, 2013 1 commit
  8. 03 Jun, 2013 1 commit
  9. 15 May, 2013 1 commit
  10. 15 Apr, 2013 1 commit
  11. 04 Apr, 2013 1 commit
  12. 26 Dec, 2012 1 commit
  13. 28 Nov, 2012 1 commit
  14. 07 Nov, 2012 2 commits
    • Ian Abbott's avatar
      PCI: Add PLX PCI 9050 workaround for some Meilhaus DAQ cards · 2794bb28
      Ian Abbott authored
      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: default avatarIan Abbott <abbotti@mev.co.uk>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      2794bb28
    • Ian Abbott's avatar
      PCI: Add workaround for PLX PCI 9050 BAR alignment erratum · 21c5fd97
      Ian Abbott authored
      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: default avatarIan Abbott <abbotti@mev.co.uk>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      21c5fd97
  15. 23 Aug, 2012 2 commits
  16. 18 Jul, 2012 1 commit
  17. 16 Jul, 2012 1 commit
  18. 10 Jul, 2012 4 commits
    • Alan Stern's avatar
      PCI: EHCI: fix crash during suspend on ASUS computers · dbf0e4c7
      Alan Stern authored
      Quite a few ASUS computers experience a nasty problem, related to the
      EHCI controllers, when going into system suspend.  It was observed
      that the problem didn't occur if the controllers were not put into the
      D3 power state before starting the suspend, and commit
      151b6128 (USB: EHCI: fix crash during
      suspend on ASUS computers) was created to do this.
      
      It turned out this approach messed up other computers that didn't have
      the problem -- it prevented USB wakeup from working.  Consequently
      commit c2fb8a3f (USB: add
      NO_D3_DURING_SLEEP flag and revert 151b6128) was merged; it
      reverted the earlier commit and added a whitelist of known good board
      names.
      
      Now we know the actual cause of the problem.  Thanks to AceLan Kao for
      tracking it down.
      
      According to him, an engineer at ASUS explained that some of their
      BIOSes contain a bug that was added in an attempt to work around a
      problem in early versions of Windows.  When the computer goes into S3
      suspend, the BIOS tries to verify that the EHCI controllers were first
      quiesced by the OS.  Nothing's wrong with this, but the BIOS does it
      by checking that the PCI COMMAND registers contain 0 without checking
      the controllers' power state.  If the register isn't 0, the BIOS
      assumes the controller needs to be quiesced and tries to do so.  This
      involves making various MMIO accesses to the controller, which don't
      work very well if the controller is already in D3.  The end result is
      a system hang or memory corruption.
      
      Since the value in the PCI COMMAND register doesn't matter once the
      controller has been suspended, and since the value will be restored
      anyway when the controller is resumed, we can work around the BIOS bug
      simply by setting the register to 0 during system suspend.  This patch
      (as1590) does so and also reverts the second commit mentioned above,
      which is now unnecessary.
      
      In theory we could do this for every PCI device.  However to avoid
      introducing new problems, the patch restricts itself to EHCI host
      controllers.
      
      Finally the affected systems can suspend with USB wakeup working
      properly.
      
      Reference: https://bugzilla.kernel.org/show_bug.cgi?id=37632
      Reference: https://bugzilla.kernel.org/show_bug.cgi?id=42728Based-on-patch-by: default avatarAceLan Kao <acelan.kao@canonical.com>
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Tested-by: default avatarDâniel Fraga <fragabr@gmail.com>
      Tested-by: default avatarJavier Marcet <jmarcet@gmail.com>
      Tested-by: default avatarAndrey Rahmatullin <wrar@wrar.name>
      Tested-by: default avatarOleksij Rempel <bug-track@fisher-privat.net>
      Tested-by: default avatarPavel Pisa <pisa@cmp.felk.cvut.cz>
      Cc: stable <stable@vger.kernel.org>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dbf0e4c7
    • Myron Stowe's avatar
      PCI: call final fixups hot-added devices · 735bff10
      Myron Stowe authored
      Final fixups are currently applied only at boot-time by
      pci_apply_final_quirks(), which is an fs_initcall().  Hot-added devices
      don't get these fixups, so they may not be completely initialized.
      
      This patch makes us run final fixups for hot-added devices in
      pci_bus_add_device() just before the new device becomes eligible for driver
      binding.
      
      This patch keeps the fs_initcall() for devices present at boot because we
      do resource assignment between pci_bus_add_device and the fs_initcall(),
      and we don't want to break any fixups that depend on that assignment.  This
      is a design issue that may be addressed in the future -- any resource
      assignment should be done *before* device_add().
      
      [bhelgaas: changelog]
      Signed-off-by: default avatarMyron Stowe <myron.stowe@redhat.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      735bff10
    • Myron Stowe's avatar
      PCI: move final fixups from __init to __devinit · 3274c8eb
      Myron Stowe authored
      Final fixups are executed during device enumeration.  If we support
      hotplug, this may be after boot, so final fixups cannot be __init.
      
      [bhelgaas: changelog]
      Signed-off-by: default avatarMyron Stowe <myron.stowe@redhat.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      3274c8eb
    • Bjorn Helgaas's avatar
      PCI: reimplement P2P bridge 1K I/O windows (Intel P64H2) · 2b28ae19
      Bjorn Helgaas authored
      9d265124 and 15a260d5 added quirks for P2P bridges that support
      I/O windows that start/end at 1K boundaries, not just the 4K boundaries
      defined by the PCI spec.  For details, see the IOBL_ADR register and the
      EN1K bit in the CNF register in the Intel 82870P2 (P64H2).
      
      These quirks complicate the code that reads P2P bridge windows
      (pci_read_bridge_io() and pci_cfg_fake_ranges()) because the bridge
      I/O resource is updated in the HEADER quirk, in pci_read_bridge_io(),
      in pci_setup_bridge(), and again in the FINAL quirk.  This is confusing
      and makes it impossible to reassign the bridge windows after FINAL
      quirks are run.
      
      This patch adds support for 1K windows in the generic paths, so the
      HEADER quirk only has to enable this support.  The FINAL quirk, which
      used to undo damage done by pci_setup_bridge(), is no longer needed.
      
      This removes "if (!res->start) res->start = ..." from pci_read_bridge_io();
      that was part of 9d265124 to avoid overwriting the resource filled in
      by the quirk.  Since pci_read_bridge_io() itself now knows about
      granularity, the quirk no longer updates the resource and this test is no
      longer needed.
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      2b28ae19
  19. 09 Jul, 2012 3 commits
  20. 18 Jun, 2012 2 commits
  21. 16 Jun, 2012 1 commit
  22. 13 Jun, 2012 1 commit
    • Alan Stern's avatar
      USB: add NO_D3_DURING_SLEEP flag and revert 151b6128 · c2fb8a3f
      Alan Stern authored
      This patch (as1558) fixes a problem affecting several ASUS computers:
      The machine crashes or corrupts memory when going into suspend if the
      ehci-hcd driver is bound to any controllers.  Users have been forced
      to unbind or unload ehci-hcd before putting their systems to sleep.
      
      After extensive testing, it was determined that the machines don't
      like going into suspend when any EHCI controllers are in the PCI D3
      power state.  Presumably this is a firmware bug, but there's nothing
      we can do about it except to avoid putting the controllers in D3
      during system sleep.
      
      The patch adds a new flag to indicate whether the problem is present,
      and avoids changing the controller's power state if the flag is set.
      Runtime suspend is unaffected; this matters only for system suspend.
      However as a side effect, the controller will not respond to remote
      wakeup requests while the system is asleep.  Hence USB wakeup is not
      functional -- but of course, this is already true in the current state
      of affairs.
      
      A similar patch has already been applied as commit
      151b6128 (USB: EHCI: fix crash during
      suspend on ASUS computers).  The patch supersedes that one and reverts
      it.  There are two differences:
      
      	The old patch added the flag at the USB level; this patch
      	adds it at the PCI level.
      
      	The old patch applied to all chipsets with the same vendor,
      	subsystem vendor, and product IDs; this patch makes an
      	exception for a known-good system (based on DMI information).
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Tested-by: default avatarDâniel Fraga <fragabr@gmail.com>
      Tested-by: default avatarAndrey Rahmatullin <wrar@wrar.name>
      Tested-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Cc: stable <stable@vger.kernel.org>
      Reviewed-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c2fb8a3f
  23. 12 Jun, 2012 3 commits
    • Alex Williamson's avatar
      PCI: add ACS validation utility · ad805758
      Alex Williamson authored
      In a PCI environment, transactions aren't always required to reach
      the root bus before being re-routed.  Intermediate switches between
      an endpoint and the root bus can redirect DMA back downstream before
      things like IOMMUs have a chance to intervene.  Legacy PCI is always
      susceptible to this as it operates on a shared bus.  PCIe added a
      new capability to describe and control this behavior, Access Control
      Services, or ACS.
      
      The utility function pci_acs_enabled() allows us to test the ACS
      capabilities of an individual devices against a set of flags while
      pci_acs_path_enabled() tests a complete path from a given downstream
      device up to the specified upstream device.  We also include the
      ability to add device specific tests as it's likely we'll see
      devices that do not implement ACS, but want to indicate support
      for various capabilities in this space.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      ad805758
    • Sebastian Andrzej Siewior's avatar
      PCI: move fixup hooks from __init to __devinit · b99ea85a
      Sebastian Andrzej Siewior authored
      The fixups are executed once the pci-device is found which is during
      boot process so __init seems fine as long as the platform does not
      support hotplug.
      
      However it is possible to remove the PCI bus at run time and have it
      rediscovered again via "echo 1 > /sys/bus/pci/rescan" and this will call
      the fixups again.
      Signed-off-by: default avatarSebastian Andrzej Siewior <sebastian@breakpoint.cc>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      b99ea85a
    • Alex Williamson's avatar
      PCI: add PCI DMA source ID quirk · 12ea6cad
      Alex Williamson authored
      DMA transactions are tagged with the source ID of the device making
      the request.  Occasionally hardware screws this up and uses the
      source ID of a different device (often the wrong function number of
      a multifunction device).  A specific Ricoh multifunction device is
      a prime example of this problem and included in this patch.
      
      Given a pci_dev, this function returns the pci_dev to use as the
      source ID for DMA.  When hardware works correctly, this returns
      the input device.  For the components of the Ricoh multifunction
      device, it returns the pci_dev for function 0.
      
      This will be used by IOMMU drivers for determining the boundaries
      of IOMMU groups as multiple devices using the same source ID must
      be contained within the same group.  This can also be used by
      existing streaming DMA paths for the same purpose.
      
      [bhelgaas: fold in pci_dev_get() for !CONFIG_PCI]
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      12ea6cad
  24. 02 May, 2012 1 commit
  25. 01 May, 2012 1 commit
  26. 05 Mar, 2012 1 commit
  27. 24 Feb, 2012 3 commits