- 17 5月, 2016 1 次提交
-
-
由 Alex Williamson 提交于
Resource flags are exposed to userspace via the sysfs "resource" file. lspci reads the sysfs file to determine resource properties. Add a "BAR Equivalent Indicator" flag so lspci can distinguish between [virtual] and [enhanced] resources. Signed-off-by: NAlex Williamson <alex.williamson@redhat.com> Signed-off-by: NSean O. Stalley <sean.stalley@intel.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 12 5月, 2016 1 次提交
-
-
由 Tomasz Nowicki 提交于
No functional changes in this patch. PCI I/O space mapping code does not depend on OF; therefore it can be moved to PCI core code. This way we will be able to use it, e.g., in ACPI PCI code. Suggested-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: NTomasz Nowicki <tn@semihalf.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> CC: Arnd Bergmann <arnd@arndb.de> CC: Liviu Dudau <Liviu.Dudau@arm.com>
-
- 20 4月, 2016 1 次提交
-
-
由 Alex Williamson 提交于
The original thought was that if a device implemented ACS, then surely we want to use that... well, it turns out that devices can make an ACS capability so broken that we still need to fall back to quirks. Reverse the order of ACS enabling to give quirks first shot at it. Signed-off-by: NAlex Williamson <alex.williamson@redhat.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 12 4月, 2016 3 次提交
-
-
由 Jacek Lawrynowicz 提交于
Solve IOMMU support issues with PCIe non-transparent bridges that use Requester ID look-up tables (RID-LUT), e.g., the PEX8733. The NTB connects devices in two independent PCI domains. Devices separated by the NTB are not able to discover each other. A PCI packet being forwared from one domain to another has to have its RID modified so it appears on correct bus and completions are forwarded back to the original domain through the NTB. The RID is translated using a preprogrammed table (LUT) and the PCI packet propagates upstream away from the NTB. If the destination system has IOMMU enabled, the packet will be discarded because the new RID is unknown to the IOMMU. Adding a DMA alias for the new RID allows IOMMU to properly recognize the packet. Each device behind the NTB has a unique RID assigned in the RID-LUT. The current DMA alias implementation supports only a single alias, so it's not possible to support mutiple devices behind the NTB when IOMMU is enabled. Enable all possible aliases on a given bus (256) that are stored in a bitset. Alias devfn is directly translated to a bit number. The bitset is not allocated for devices that have no need for DMA aliases. More details can be found in the following article: http://www.plxtech.com/files/pdf/technical/expresslane/RTC_Enabling%20MulitHostSystemDesigns.pdfSigned-off-by: NJacek Lawrynowicz <jacek.lawrynowicz@intel.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NAlex Williamson <alex.williamson@redhat.com> Acked-by: NDavid Woodhouse <David.Woodhouse@intel.com> Acked-by: NJoerg Roedel <jroedel@suse.de>
-
由 Bjorn Helgaas 提交于
One of the quirks that adds DMA aliases logs an informational message in dmesg. Move that to pci_add_dma_alias() so all users log the message consistently. No functional change intended (except extra message). Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NAlex Williamson <alex.williamson@redhat.com>
-
由 Bjorn Helgaas 提交于
Add a pci_add_dma_alias() interface to encapsulate the details of adding an alias. No functional change intended. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NAlex Williamson <alex.williamson@redhat.com>
-
- 06 4月, 2016 1 次提交
-
-
由 Colin Ian King 提交于
Fix spelling of "initalization". [bhelgaas: also fix pci/pci.c] Signed-off-by: NColin Ian King <colin.king@canonical.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 11 3月, 2016 1 次提交
-
-
由 Alex Williamson 提交于
Some devices take longer than the spec indicates to return from FLR reset, a notable case of this is Intel integrated graphics (IGD), which can often take an additional 300ms powering down an attached LCD panel as part of the FLR. Allow devices up to 1000ms, testing every 100ms whether the second dword of config space is read as -1. Signed-off-by: NAlex Williamson <alex.williamson@redhat.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 08 3月, 2016 2 次提交
-
-
pci_create_root_bus() passes a "parent" pointer to pci_bus_assign_domain_nr(). When CONFIG_PCI_DOMAINS_GENERIC is defined, pci_bus_assign_domain_nr() dereferences that pointer. Many callers of pci_create_root_bus() supply a NULL "parent" pointer, which leads to a NULL pointer dereference error. 7c674700 ("PCI: Move domain assignment from arm64 to generic code") moved the "parent" dereference from arm64 to generic code. Only arm64 used that code (because only arm64 defined CONFIG_PCI_DOMAINS_GENERIC), and it always supplied a valid "parent" pointer. Other arches supplied NULL "parent" pointers but didn't defined CONFIG_PCI_DOMAINS_GENERIC, so they used a no-op version of pci_bus_assign_domain_nr(). 8c7d1474 ("ARM/PCI: Move to generic PCI domains") defined CONFIG_PCI_DOMAINS_GENERIC on ARM, and many ARM platforms use pci_common_init(), which supplies a NULL "parent" pointer. These platforms (cns3xxx, dove, footbridge, iop13xx, etc.) crash with a NULL pointer dereference like this while probing PCI: Unable to handle kernel NULL pointer dereference at virtual address 000000a4 PC is at pci_bus_assign_domain_nr+0x10/0x84 LR is at pci_create_root_bus+0x48/0x2e4 Kernel panic - not syncing: Attempted to kill init! [bhelgaas: changelog, add "Reported:" and "Fixes:" tags] Reported: http://forum.doozan.com/read.php?2,17868,22070,quote=1 Fixes: 8c7d1474 ("ARM/PCI: Move to generic PCI domains") Fixes: 7c674700 ("PCI: Move domain assignment from arm64 to generic code") Signed-off-by: NKrzysztof Hałasa <khalasa@piap.pl> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> CC: stable@vger.kernel.org # v4.0+
-
由 Bjorn Helgaas 提交于
Christoph added a generic include/linux/pci-dma-compat.h, so now there's one place with most of the PCI DMA interfaces. Move more PCI DMA-related things there: - The PCI_DMA_* direction constants from linux/pci.h - The pci_set_dma_max_seg_size() and pci_set_dma_seg_boundary() CONFIG_PCI implementations from drivers/pci/pci.c - The pci_set_dma_max_seg_size() and pci_set_dma_seg_boundary() !CONFIG_PCI stubs from linux/pci.h - The pci_set_dma_mask() and pci_set_consistent_dma_mask() !CONFIG_PCI stubs from linux/pci.h Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 06 2月, 2016 1 次提交
-
-
由 Bjorn Helgaas 提交于
include/asm-generic/pci-bridge.h is now empty, so remove every #include of it. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: Will Deacon <will.deacon@arm.com> (arm64)
-
- 09 1月, 2016 2 次提交
-
-
由 Geliang Tang 提交于
Use to_pci_dev() instead of open-coding it. Signed-off-by: NGeliang Tang <geliangtang@163.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bogicevic Sasa 提交于
Fix all whitespace issues (missing or needed whitespace) in all files in drivers/pci. Code is compiled with allyesconfig before and after code changes and objects are recorded and checked with objdiff and they are not changed after this commit. Signed-off-by: NBogicevic Sasa <brutallesale@gmail.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 09 12月, 2015 1 次提交
-
-
由 Julia Lawall 提交于
The pci_platform_pm_ops structure is never modified, so declare it as const. Done with the help of Coccinelle. Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr> Acked-by: NBjorn Helgaas <bhelgaas@google.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 30 10月, 2015 4 次提交
-
-
由 Bjorn Helgaas 提交于
An Enhanced Allocation Capability entry with BEI 0 fills in dev->resource[0] just like a real BAR 0 would, but non-EA experts might not connect "EA - BEI 0" with BAR 0. Decode the EA jargon a little bit, e.g., change this: pci 0002:01:00.0: EA - BEI 0, Prop 0x00: [mem 0x84300000-0x84303fff] to this: pci 0002:01:00.0: BAR 0: [mem 0x84300000-0x84303fff] (from Enhanced Allocation, properties 0x00) Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
Expand bitmask #defines completely. This puts the shift in the code instead of in the #define, but it makes it more obvious in the header file how fields in the register are laid out. No functional change. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 David Daney 提交于
SR-IOV BARs can be specified via EA entries. Extend the EA parser to extract the SRIOV BAR resources, and modify sriov_init() to use resources previously obtained via EA. Signed-off-by: NDavid Daney <david.daney@cavium.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NSean O. Stalley <sean.stalley@intel.com>
-
由 Sean O. Stalley 提交于
Add support for devices using Enhanced Allocation entries instead of BARs. This allows the kernel to parse the EA Extended Capability structure in PCI config space and claim the BAR-equivalent resources. See https://pcisig.com/sites/default/files/specification_documents/ECN_Enhanced_Allocation_23_Oct_2014_Final.pdf [bhelgaas: add spec URL, s/pci_ea_set_flags/pci_ea_flags/, consolidate declarations, print unknown property in hex to match spec] Signed-off-by: NSean O. Stalley <sean.stalley@intel.com> [david.daney@cavium.com: Add more support/checking for Entry Properties, allow EA behind bridges, rewrite some error messages.] Signed-off-by: NDavid Daney <david.daney@cavium.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 23 10月, 2015 1 次提交
-
-
由 Hariprasad Shenai 提交于
The Chelsio T5 has a PCIe compliance erratum that causes Malformed TLP or Unexpected Completion errors in some systems, which may cause device access timeouts. Per PCIe r3.0, sec 2.2.9, "Completion headers must supply the same values for the Attribute as were supplied in the header of the corresponding Request, except as explicitly allowed when IDO is used." Instead of copying the Attributes from the Request to the Completion, the T5 always generates Completions with zero Attributes. The receiver of a Completion whose Attributes don't match the Request may accept it (which itself seems non-compliant based on sec 2.3.2), or it may handle it as a Malformed TLP or an Unexpected Completion, which will probably lead to a device access timeout. Work around this by disabling "Relaxed Ordering" and "No Snoop" in the Root Port so it always generate Requests with zero Attributes. This does affect all other devices which are downstream of that Root Port, but these are performance optimizations that should not make a functional difference. Note that Configuration Space accesses are never supposed to have TLP Attributes, so we're safe waiting till after any Configuration Space accesses to do the Root Port "fixup". Based on original work by Casey Leedom <leedom@chelsio.com> [bhelgaas: changelog, comments, rename to pci_find_pcie_root_port(), rework to use pci_upstream_bridge() and check for Root Port device type, edit diagnostics to clarify intent and devices affected] Signed-off-by: NHariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 13 10月, 2015 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Commit bac2a909 (PCI / PM: Avoid resuming PCI devices during system suspend) introduced a mechanism by which some PCI devices that were runtime-suspended at the system suspend time might be left in that state for the duration of the system suspend-resume cycle. However, it overlooked devices that were marked as capable of waking up the system just because PME support was detected in their PCI config space. Namely, in that case, device_can_wakeup(dev) returns 'true' for the device and if the device is not configured for system wakeup, device_may_wakeup(dev) returns 'false' and it will be resumed during system suspend even though configuring it for system wakeup may not really make sense at all. To avoid this problem, simply disable PME for PCI devices that have not been configured for system wakeup and are runtime-suspended at the system suspend time for the duration of the suspend-resume cycle. If the device is in D3cold, its config space is not available and it shouldn't be written to, but that's only possible if the device has platform PM support and the platform code is responsible for checking whether or not the device's configuration is suitable for system suspend in that case. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 17 9月, 2015 1 次提交
-
-
由 Taku Izumi 提交于
AER errors might be recorded when powering-on devices. These errors can be ignored, so firmware usually clears them before the OS enumerates devices. However, firmware is not involved when devices are added via hotplug, so the OS may discover power-up errors that should be ignored. The same may happen when powering up devices when resuming after suspend. Clear the AER error status registers during enumeration and resume. [bhelgaas: changelog, remove repetitive comments] Signed-off-by: NTaku Izumi <izumi.taku@jp.fujitsu.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 14 9月, 2015 1 次提交
-
-
由 Wei Yang 提交于
VF BARs are read-only zero, so updating VF BARs will not have any effect. See the SR-IOV spec r1.1, sec 3.4.1.11. Don't update VF BARs in pci_restore_bars(). This avoids spurious "BAR %d: error updating" messages that we see when doing vfio pass-through after 6eb70187 ("vfio-pci: Move idle devices to D3hot power state"). [bhelgaas: changelog, fix whitespace] Signed-off-by: NWei Yang <weiyang@linux.vnet.ibm.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 25 8月, 2015 1 次提交
-
-
由 Luis R. Rodriguez 提交于
This lets drivers take advantage of PAT when available. It should help with the transition of converting video drivers over to ioremap_wc() to help with the goal of eventually using _PAGE_CACHE_UC over _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache(), see: de33c442 ("x86 PAT: fix performance drop for glx, use UC minus for ioremap(), ioremap_nocache() and pci_mmap_page_range()") Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com> Signed-off-by: NBorislav Petkov <bp@suse.de> Acked-by: NArnd Bergmann <arnd@arndb.de> Cc: <syrjala@sci.fi> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Antonino Daplas <adaplas@gmail.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Dave Airlie <airlied@redhat.com> Cc: Davidlohr Bueso <dbueso@suse.de> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Juergen Gross <jgross@suse.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mel Gorman <mgorman@suse.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Suresh Siddha <sbsiddha@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Toshi Kani <toshi.kani@hp.com> Cc: Ville Syrjälä <syrjala@sci.fi> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: airlied@linux.ie Cc: benh@kernel.crashing.org Cc: dan.j.williams@intel.com Cc: konrad.wilk@oracle.com Cc: linux-fbdev@vger.kernel.org Cc: linux-pci@vger.kernel.org Cc: mst@redhat.com Cc: vinod.koul@intel.com Cc: xen-devel@lists.xensource.com Link: http://lkml.kernel.org/r/1440443613-13696-2-git-send-email-mcgrof@do-not-panic.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
- 24 8月, 2015 1 次提交
-
-
由 Keith Busch 提交于
Firmware typically configures the PCIe fabric with a consistent Max Payload Size setting based on the devices present at boot. A hot-added device typically has the power-on default MPS setting (128 bytes), which may not match the fabric. The previous Linux default, in the absence of any "pci=pcie_bus_*" options, was PCIE_BUS_TUNE_OFF, in which we never touch MPS, even for hot-added devices. Add a new default setting, PCIE_BUS_DEFAULT, in which we make sure every device's MPS setting matches the upstream bridge. This makes it more likely that a hot-added device will work in a system with optimized MPS configuration. Note that if we hot-add a device that only supports 128-byte MPS, it still likely won't work because we don't reconfigure the rest of the fabric. Booting with "pci=pcie_bus_peer2peer" is a workaround for this because it sets MPS to 128 for everything. [bhelgaas: changelog, new default, rework for pci_configure_device() path] Tested-by: NKeith Busch <keith.busch@intel.com> Tested-by: NJordan Hargrave <jharg93@gmail.com> Signed-off-by: NKeith Busch <keith.busch@intel.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NYinghai Lu <yinghai@kernel.org>
-
- 21 7月, 2015 1 次提交
-
-
由 Alexander Duyck 提交于
Previously we did not restore ACS state after a PCIe reset. This meant that we could not reassign interfaces after a system suspend because the D0->D3 transition disabled ACS, and we didn't restore it when going back to D0. Restore ACS configuration in pci_restore_state(). [bhelgaas: changelog] Signed-off-by: NAlexander Duyck <alexander.h.duyck@redhat.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> CC: Allen Kay <allen.m.kay@intel.com> CC: Chris Wright <chris@sous-sol.org> CC: Alex Williamson <alex.williamson@redhat.com>
-
- 15 7月, 2015 3 次提交
-
-
由 Bjorn Helgaas 提交于
Remove redundant code from __pci_bus_find_cap_start(). No functional change. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Wei Yang 提交于
The return value of the pci_find_(ext_)capability() is either zero or the position of a capability. It is never negative. This patch consolidates the form of check from (pos <= 0) to (!pos). Signed-off-by: NWei Yang <weiyang@linux.vnet.ibm.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Wei Yang 提交于
Some quirks search for a HyperTransport capability and use a hard-coded TTL value of 48 to avoid an infinite loop. Move the definition of PCI_FIND_CAP_TTL to pci.h and use it instead of the hard-coded TTL values. [bhelgaas: changelog] Signed-off-by: NWei Yang <weiyang@linux.vnet.ibm.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 23 5月, 2015 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Refine the mechanism introduced by commit f244d8b6 ("ACPIPHP / radeon / nouveau: Fix VGA switcheroo problem related to hotplug") to propagate the ignore_hotplug setting of the device to its parent bridge in case hotplug notifications related to the graphics adapter switching are given for the bridge rather than for the device itself (they need to be ignored in both cases). Link: https://bugzilla.kernel.org/show_bug.cgi?id=61891 Link: https://bugs.freedesktop.org/show_bug.cgi?id=88927 Fixes: b440bde7 ("PCI: Add pci_ignore_hotplug() to ignore hotplug events for a device") Reported-and-tested-by: Ntiagdtd-lava <tiagdtd-lava@yahoo.de> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.17+
-
- 07 5月, 2015 1 次提交
-
-
由 Bjorn Helgaas 提交于
pci_msi_off() is unused, so remove it. Removes the exported symbol pci_msi_off(). Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 10 4月, 2015 1 次提交
-
-
由 Sean O. Stalley 提交于
Reading both the capability ID and "next" pointer at the same time lets us parse the list with half the number of config reads. Signed-off-by: NSean O. Stalley <sean.stalley@intel.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 09 4月, 2015 1 次提交
-
-
由 Ray Jui 提交于
Export the following symbols so they can be referenced by a PCI host bridge driver compiled as a kernel loadable module: pci_common_swizzle pci_create_root_bus pci_stop_root_bus pci_remove_root_bus pci_assign_unassigned_bus_resources pci_fixup_irqs Signed-off-by: NRay Jui <rjui@broadcom.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NArnd Bergmann <arnd@arndb.de>
-
- 13 3月, 2015 2 次提交
-
-
由 Bjorn Helgaas 提交于
Make pci_ioremap_bar() fail if we're trying to map a BAR that hasn't been assigned. Normally pci_enable_device() will fail if a BAR hasn't been assigned, but a driver can successfully call pci_enable_device_io() even if a memory BAR hasn't been assigned. That driver should not be able to use pci_ioremap_bar() to map that unassigned memory BAR. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Bjorn Helgaas 提交于
Use dev_warn() to complain about a pci_ioremap_bar() failure so we can include the driver name, BAR number, and the resource itself. We could use dev_WARN() to also get the backtrace as we did previously, but I think that's more information than we need. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 24 1月, 2015 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Commit f25c0ae2 (ACPI / PM: Avoid resuming devices in ACPI PM domain during system suspend) modified the ACPI PM domain's system suspend callbacks to allow devices attached to it to be left in the runtime-suspended state during system suspend so as to optimize the suspend process. This was based on the general mechanism introduced by commit aae4518b (PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily). Extend that approach to PCI devices by modifying the PCI bus type's ->prepare callback to return 1 for devices that are runtime-suspended when it is being executed and that are in a suitable power state and need not be resumed going forward. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 17 1月, 2015 2 次提交
-
-
由 Alex Williamson 提交于
Per the PCI Power Management spec r1.2, sec 3.2.4, a device that advertises No_Soft_Reset == 0 in the PMCSR register (reported by lspci as "NoSoftRst-") should perform an internal reset when transitioning from D3hot to D0 via software control. Configuration context is lost and the device requires a full reinitialization sequence. Unfortunately the definition of "internal reset", beyond the application of the configuration context, is largely left to the interpretation of the specific device. Some devices don't seem to perform an "internal reset" even if they report No_Soft_Reset == 0. We still need to honor the PCI specification and restore PCI config context in the event that we do a PM reset, so we don't cache and modify the PCI_PM_CTRL_NO_SOFT_RESET bit for the device, but for interfaces where the intention is to reset the device, like pci_reset_function(), we need a mechanism to flag that PM reset (a D3hot->D0 transition) doesn't perform any significant "internal reset" of the device. Signed-off-by: NAlex Williamson <alex.williamson@redhat.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Alex Williamson 提交于
Enable a mechanism for devices to quirk that they do not behave when doing a PCI bus reset. We require a modest level of spec compliant behavior in order to do a reset, for instance the device should come out of reset without throwing errors and PCI config space should be accessible after reset. This is too much to ask for some devices. Link: http://lkml.kernel.org/r/20140923210318.498dacbd@dualc.maya.orgSigned-off-by: NAlex Williamson <alex.williamson@redhat.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.14+
-
- 28 12月, 2014 1 次提交
-
-
由 Lorenzo Pieralisi 提交于
The current logic in arm64 pci_bus_assign_domain_nr() is flawed in that depending on the host controller configuration for a platform and the initialization sequence, core code may end up allocating PCI domain numbers from both DT and the generic domain counter, which would result in PCI domain allocation aliases/errors. Fix the logic behind the PCI domain number assignment and move the resulting code to the PCI core so the same domain allocation logic is used on all platforms that select CONFIG_PCI_DOMAINS_GENERIC. [bhelgaas: tidy changelog] Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NLiviu Dudau <Liviu.Dudau@arm.com> Acked-by: NArnd Bergmann <arnd@arndb.de> CC: Rob Herring <robh+dt@kernel.org> CC: Catalin Marinas <catalin.marinas@arm.com>
-
- 04 12月, 2014 1 次提交
-
-
由 Konrad Rzeszutek Wilk 提交于
We have the pci_load_and_free_saved_state, and pci_store_saved_state but are missing the functionality to just load the state multiple times in the PCI device without having to free/save the state. This patch makes it possible to use this function. Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com> Acked-by: NBjorn Helgaas <bhelgaas@google.com> Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
-
- 20 11月, 2014 1 次提交
-
-
由 Myron Stowe 提交于
pci_iov_resource_bar() always sets its 'pci_bar_type' parameter to 'pci_bar_unknown'. Drop the parameter and just use 'pci_bar_unknown' directly in the callers. No functional change intended. Signed-off-by: NMyron Stowe <myron.stowe@redhat.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> CC: Chris Wright <chrisw@sous-sol.org> CC: Yu Zhao <yuzhao@google.com>
-