An error occurred fetching the project authors.
- 30 Sep, 2015 1 commit
-
-
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: Bjorn Helgaas <bhelgaas@google.com> CC: Hemant Pedanekar <hemantp@ti.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
- 18 Sep, 2015 1 commit
-
-
Mark Rustad authored
commit 7aa6ca4d upstream. Set the PCI_DEV_FLAGS_VPD_REF_F0 flag on all Intel Ethernet device functions other than function 0, so that on multi-function devices, we will always read VPD from function 0 instead of from the other functions. [bhelgaas: changelog] Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Alexander Duyck <alexander.h.duyck@redhat.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
- 31 Oct, 2014 1 commit
-
-
Douglas Lehr authored
commit 9fe373f9 upstream. The Crocodile chip occasionally comes up with 4k and 8k BAR sizes. Due to an erratum, setting the SR-IOV page size causes the physical function BARs to expand to the system page size. Since ppc64 uses 64k pages, when Linux tries to assign the smaller resource sizes to the now 64k BARs the address will be truncated and the BARs will overlap. Force Linux to allocate the resource as a full page, which avoids the overlap. [bhelgaas: print expanded resource, too] Signed-off-by: Douglas Lehr <dllehr@us.ibm.com> Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Milton Miller <miltonm@us.ibm.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
- 17 Jul, 2014 1 commit
-
-
Thomas Jarosch authored
commit 7c82126a upstream. After a CPU upgrade while keeping the same mainboard, we faced "spurious interrupt" problems again. It turned out that the new CPU also featured a new GPU with a different PCI ID. Add this PCI ID to the quirk table. Probably all other Intel GPU PCI IDs are affected, too, but I don't want to add them without a test system. See f67fd55f ("PCI: Add quirk for still enabled interrupts on Intel Sandy Bridge GPUs") for some history. [bhelgaas: add f67fd55f reference, stable tag] Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
- 12 Aug, 2013 2 commits
-
-
Casey Leedom authored
New routine has been added to avoid duplication of code to wait for pending PCI transactions to complete. This makes use of that function. Signed-off-by: Casey Leedom <leedom@chelsio.com> Signed-off-by: Vipul Pandya <vipul@chelsio.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Casey Leedom authored
T4 can wedge if there are DMAs in flight within the chip and Bus Master has been disabled. We need to have it on till the Function Level Reset completes. T4 can also suffer a Head Of Line blocking problem if MSI-X interrupts are disabled before the FLR has completed. Signed-off-by: Casey Leedom <leedom@chelsio.com> Signed-off-by: Vipul Pandya <vipul@chelsio.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
- 25 Jul, 2013 1 commit
-
-
Alex Williamson authored
AMD confirmed that peer-to-peer between these devices is not possible. We can therefore claim that they support a subset of ACS. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Donald Dutile <ddutile@redhat.com>
-
- 18 Jun, 2013 1 commit
-
-
Yijing Wang authored
PCI PM cap register offset has been saved in pci_pm_init(), so we can use pdev->pm_cap instead of using pci_find_capability(..) here. Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 03 Jun, 2013 1 commit
-
-
Shane Huang authored
To add AMD CZ SATA controller device ID of IDE mode. [bhelgaas: drop pci_ids.h update] Signed-off-by: Shane Huang <shane.huang@amd.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Tejun Heo <tj@kernel.org> Cc: stable@vger.kernel.org
-
- 15 May, 2013 1 commit
-
-
Jon Mason authored
Certain NTB devices have a hardware erratum where, regardless of pre-configured value, reading the BAR size returns 4096. To work around this issue, add a PCI quirk to read the appropriate values from an alternative register in PCI config space and move the resource endpoints to the appropriate location. Signed-off-by: Jon Mason <jon.mason@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
- 15 Apr, 2013 1 commit
-
-
Yinghai Lu authored
Before every call of quirk_io_region(), pci_read_config_word() is called. We can fold that call into quirk_io_region() to make code more readable. [bhelgaas: changelog, fill bus_region directly rather than copying from res] Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
- 04 Apr, 2013 1 commit
-
-
Xiong Huang authored
The following PCIe devices with revision lower than 0x18 have this bug: AR8161(1091)/AR8162(1090)/AR8171(10A1)/AR8172(10A0)/E210X(E091). Signed-off-by: Huang,Xiong <xiong@qca.qualcomm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Wei Yang <weiyang@linux.vnet.ibm.com>
-
- 26 Dec, 2012 1 commit
-
-
Andy Lutomirski authored
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: Andy Lutomirski <luto@amacapital.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Chris Ball <cjb@laptop.org> CC: Manoj Iyer <manoj.iyer@canonical.com> CC: stable@vger.kernel.org
-
- 28 Nov, 2012 1 commit
-
-
Bill Pemberton authored
CONFIG_HOTPLUG is going away as an option so __devexit_p, __devint, __devinitdata, __devinitconst, and _devexit are no longer needed. Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 07 Nov, 2012 2 commits
-
-
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: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
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: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
- 23 Aug, 2012 2 commits
-
-
Bjorn Helgaas authored
Before initiating an FLR, we should wait for completion of any outstanding non-posted requests. See PCIe spec r3.0, sec 6.6.2. This makes reset_intel_82599_sfp_virtfn() very similar to the generic pcie_flr(). The only difference is that the 82599 doesn't report FLR support in the VF Device Capability register. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Jiang Liu authored
Use PCI Express Capability access functions to simplify core. Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
- 18 Jul, 2012 1 commit
-
-
Chris Metcalf authored
This change implements PCIe root complex support for tilegx using the kernel support layer for accessing the TRIO hardware shim. Reviewed-by: Bjorn Helgaas <bhelgaas@google.com> [changes in 07487f3] Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
-
- 16 Jul, 2012 1 commit
-
-
Myron Stowe authored
My "PCI: Integrate 'pci_fixup_final' quirks into hot-plug paths" patch introduced an undefined reference to 'pci_fixup_final_inited' when CONFIG_PCI_QUIRKS is not enabled (on x86_64): drivers/built-in.o: In function `pci_bus_add_device': (.text+0x4f62): undefined reference to `pci_fixup_final_inited' This patch removes the external reference ending up with a result closer to what we ultimately want when the boot path issues described in the original patch are resolved. References: https://lkml.org/lkml/2012/7/9/542 Original, offending, patch https://lkml.org/lkml/2012/7/12/338 Randy's catch Reported-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Myron Stowe <myron.stowe@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Randy Dunlap <rdunlap@xenotime.net>
-
- 10 Jul, 2012 4 commits
-
-
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: AceLan Kao <acelan.kao@canonical.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Dâniel Fraga <fragabr@gmail.com> Tested-by: Javier Marcet <jmarcet@gmail.com> Tested-by: Andrey Rahmatullin <wrar@wrar.name> Tested-by: Oleksij Rempel <bug-track@fisher-privat.net> Tested-by: Pavel Pisa <pisa@cmp.felk.cvut.cz> Cc: stable <stable@vger.kernel.org> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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: Myron Stowe <myron.stowe@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
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: Myron Stowe <myron.stowe@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
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: Bjorn Helgaas <bhelgaas@google.com>
-
- 09 Jul, 2012 3 commits
-
-
Myron Stowe authored
The enable/suspend/resume_early/resume fixups can be called at any time, so they can't be __init or __devinit. [bhelgaas: changelog] Signed-off-by: Myron Stowe <myron.stowe@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Myron Stowe authored
__nv_msi_ht_cap_quirk() acquires a temporary reference via 'pci_get_bus_and_slot()' that is never released. This patch releases the temporary reference. Signed-off-by: Myron Stowe <myron.stowe@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Myron Stowe authored
This patch restructures pci_do_fixups()'s quirk invocations in the style of initcall_debug_start() and initcall_debug_report(), so we have only one call site for the quirk. [bhelgaas: changelog] Signed-off-by: Myron Stowe <myron.stowe@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
- 18 Jun, 2012 2 commits
-
-
Alex Williamson authored
Passes pci_intx_mask_supported test but continues to send interrupts as discovered through VFIO-based device assignment. http://www.spinics.net/lists/kvm/msg73738.html [bhelgaas: use HEADER, not FINAL, which is currently broken for hotplug] Tested-by: Andreas Hartmann <andihartmann@01019freenet.de> Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
Jan Kiszka authored
According to http://thread.gmane.org/gmane.comp.emulators.kvm.devel/91388 the T310 does not properly support INTx masking as it fails to keep the PCI_STATUS_INTERRUPT bit updated once the interrupt is masked. Mark this adapter as broken so that pci_intx_mask_supported won't report it as compatible. [bhelgaas: use HEADER, not FINAL, which is currently broken for hotplug] Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
- 16 Jun, 2012 1 commit
-
-
Bjorn Helgaas authored
pci_intx_mask_supported() assumes INTx masking is supported if the PCI_COMMAND_INTX_DISABLE bit is writable. But when that bit is set, some devices don't actually mask INTx or update PCI_STATUS_INTERRUPT as we expect. This patch adds a way for quirks to identify these broken devices. [bhelgaas: split out from Chelsio quirk addition] Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
- 13 Jun, 2012 1 commit
-
-
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: Alan Stern <stern@rowland.harvard.edu> Tested-by: Dâniel Fraga <fragabr@gmail.com> Tested-by: Andrey Rahmatullin <wrar@wrar.name> Tested-by: Steven Rostedt <rostedt@goodmis.org> Cc: stable <stable@vger.kernel.org> Reviewed-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 12 Jun, 2012 3 commits
-
-
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: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
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: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
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: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
- 02 May, 2012 1 commit
-
-
Xudong Hao authored
For IvyBridge Mobile platform, a system hang may occur if a FLR (Function Level Reset) is asserted to internal graphics. This quirk is a workaround for the IVB FLR errata issue. We are disabling the FLR reset handshake between the PCH and CPU display, then manually powering down the panel power sequencing and resetting the PCH display. Signed-off-by: Xudong Hao <xudong.hao@intel.com> Signed-off-by: Kay, Allen M <allen.m.kay@intel.com> Signed-off-by: Matthew Wilcox <matthew.r.wilcox@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-
- 01 May, 2012 1 commit
-
-
Huang, Xiong authored
All supported devices have one issue that msi interrupt doesn't assert if pci command register bit (PCI_COMMAND_INTX_DISABLE) is set. Add workaround in drivers/pci/quirks.c Signed-off-by: xiong <xiong@qca.qualcomm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 05 Mar, 2012 1 commit
-
-
Matt Carlson authored
This patch recodes the MRRS cap for 5719 A0 devices as a PCI quirk. Signed-off-by: Matt Carlson <mcarlson@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 24 Feb, 2012 3 commits
-
-
Yinghai Lu authored
Makes it a little easier to figure out which device may have caused a slow quirk. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Cc: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-
Yinghai Lu authored
This isn't really a quirk; calling it directly from pci_add_device makes more sense. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-
Yinghai Lu authored
Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
-