summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2014-03-20Merge branch 'pci/resource' into nextBjorn Helgaas8-88/+120
* pci/resource: (26 commits) Revert "[PATCH] Insert GART region into resource map" PCI: Log IDE resource quirk in dmesg PCI: Change pci_bus_alloc_resource() type_mask to unsigned long PCI: Check all IORESOURCE_TYPE_BITS in pci_bus_alloc_from_region() resources: Set type in __request_region() PCI: Don't check resource_size() in pci_bus_alloc_resource() s390/PCI: Use generic pci_enable_resources() tile PCI RC: Use default pcibios_enable_device() sparc/PCI: Use default pcibios_enable_device() (Leon only) sh/PCI: Use default pcibios_enable_device() microblaze/PCI: Use default pcibios_enable_device() alpha/PCI: Use default pcibios_enable_device() PCI: Add "weak" generic pcibios_enable_device() implementation PCI: Don't enable decoding if BAR hasn't been assigned an address PCI: Mark 64-bit resource as IORESOURCE_UNSET if we only support 32-bit PCI: Don't try to claim IORESOURCE_UNSET resources PCI: Check IORESOURCE_UNSET before updating BAR PCI: Don't clear IORESOURCE_UNSET when updating BAR PCI: Mark resources as IORESOURCE_UNSET if we can't assign them PCI: Remove pci_find_parent_resource() use for allocation ...
2014-03-20Merge branch 'pci/misc' into nextBjorn Helgaas1-0/+3
* pci/misc: PCI: Enable INTx in pci_reenable_device() only when MSI/MSI-X not enabled
2014-03-20PCI: Log IDE resource quirk in dmesgBjorn Helgaas1-4/+12
Make a note in dmesg when we overwrite legacy IDE BAR info. We previously logged something like this: pci 0000:00:1f.1: reg 0x10: [io 0x0000-0x0007] and then silently overwrote the resource. There's an example in the bugzilla below. This doesn't fix the bugzilla; it just makes what's going on more obvious. No functional change; merely adds some dev_info() calls. Link: https://bugzilla.kernel.org/show_bug.cgi?id=48451 Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-03-20PCI: Change pci_bus_alloc_resource() type_mask to unsigned longBjorn Helgaas1-2/+2
The pci_bus_alloc_resource() "type_mask" parameter is used to compare with the "flags" member of a struct resource, so it should be the same type, namely "unsigned long". No functional change because all current IORESOURCE_* flags fit in 32 bits. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-03-20PCI: Check all IORESOURCE_TYPE_BITS in pci_bus_alloc_from_region()Bjorn Helgaas1-1/+1
When allocating space from a bus resource, i.e., from apertures leading to this bus, make sure the entire resource type matches. The previous code assumed the IORESOURCE_TYPE_BITS field was a bitmask with only a single bit set, but this is not true. IORESOURCE_TYPE_BITS is really an enumeration, and we have to check all the bits. See 72dcb1197228 ("resources: Add register address resource type"). No functional change. If we used this path for allocating IRQs, DMA channels, or bus numbers, this would fix a bug because those types are indistinguishable when masked by IORESOURCE_IO | IORESOURCE_MEM. But we don't, so this shouldn't make any difference. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-03-20PCI: Don't check resource_size() in pci_bus_alloc_resource()Bjorn Helgaas1-2/+0
Paul reported that after f75b99d5a77d ("PCI: Enforce bus address limits in resource allocation") on a 32-bit kernel (CONFIG_PHYS_ADDR_T_64BIT not set), intel-gtt complained "can't ioremap flush page - no chipset flushing". In addition, other PCI resource allocations, e.g., for bridge windows, failed. This happens because we incorrectly skip bus resources of [mem 0x00000000-0xffffffff] because we think they are of size zero. When resource_size_t is 32 bits wide, resource_size() on [mem 0x00000000-0xffffffff] returns 0 because (r->end - r->start + 1) overflows. Therefore, we can't use "resource_size() == 0" to decide that allocation from this resource will fail. allocate_resource() should fail anyway if it can't satisfy the address constraints, so we should just depend on that. A [mem 0x00000000-0xffffffff] bus resource is obviously not really valid, but we do fall back to it as a default when we don't have information about host bridge apertures. Link: https://bugzilla.kernel.org/show_bug.cgi?id=71611 Fixes: f75b99d5a77d PCI: Enforce bus address limits in resource allocation Reported-and-tested-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-03-20PCI: Add "weak" generic pcibios_enable_device() implementationBjorn Helgaas1-0/+5
Many architectures implement pcibios_enable_device() the same way, so provide a default implementation in the core. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-03-20PCI: Don't enable decoding if BAR hasn't been assigned an addressBjorn Helgaas1-2/+8
Don't enable memory or I/O decoding if we haven't assigned or claimed the BAR's resource. If we enable decoding for a BAR that hasn't been assigned an address, we'll likely cause bus conflicts. This declines to enable decoding for resources with IORESOURCE_UNSET. Note that drivers can use pci_enable_device_io() or pci_enable_device_mem() if they only care about specific types of BARs. In that case, we don't bother checking whether the corresponding resources are assigned or claimed. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-03-08PCI: Enable INTx in pci_reenable_device() only when MSI/MSI-X not enabledBjorn Helgaas1-0/+3
Andreas reported that after 1f42db786b14 ("PCI: Enable INTx if BIOS left them disabled"), pciehp surprise removal stopped working. This happens because pci_reenable_device() on the hotplug bridge (used in the pciehp_configure_device() path) clears the Interrupt Disable bit, which apparently breaks the bridge's MSI hotplug event reporting. Previously we cleared the Interrupt Disable bit in do_pci_enable_device(), which is used by both pci_enable_device() and pci_reenable_device(). But we use pci_reenable_device() after the driver may have enabled MSI or MSI-X, and we *set* Interrupt Disable as part of enabling MSI/MSI-X. This patch clears Interrupt Disable only when MSI/MSI-X has not been enabled. Fixes: 1f42db786b14 PCI: Enable INTx if BIOS left them disabled Link: https://bugzilla.kernel.org/show_bug.cgi?id=71691 Reported-and-tested-by: Andreas Noever <andreas.noever@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2014-02-27PCI: Mark 64-bit resource as IORESOURCE_UNSET if we only support 32-bitBjorn Helgaas1-0/+1
If we don't support 64-bit addresses, i.e., CONFIG_PHYS_ADDR_T_64BIT is not set, we can't deal with BARs above 4GB. In this case we already pretend the BAR contained zero; this patch also sets IORESOURCE_UNSET so we can try to reallocate it later. I don't think this is exactly correct: what we care about here are *bus* addresses, not CPU addresses, so the tests of sizeof(resource_size_t) probably should be on sizeof(dma_addr_t) instead. But this is what's been in -next, so we'll fix that later. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-27PCI: Don't try to claim IORESOURCE_UNSET resourcesBjorn Helgaas1-5/+10
If the IORESOURCE_UNSET bit is set, it means we haven't assigned an address yet, so don't try to claim the region. Also, make the error messages more uniform and add info about which BAR is involved. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-27PCI: Check IORESOURCE_UNSET before updating BARBjorn Helgaas1-0/+3
Check to make sure we don't update a BAR with an address we haven't assigned. If we haven't assigned an address to a resource, we shouldn't write it to a BAR. This isn't a problem for the usual path via pci_assign_resource(), which clears IORESOURCE_UNSET before calling pci_update_resource(), but paths like pci_restore_bars() can call this for resources we haven't assigned. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-27PCI: Don't clear IORESOURCE_UNSET when updating BARBjorn Helgaas1-5/+0
Clear IORESOURCE_UNSET when we assign an address to a resource, not when we write the address to the BAR. Also, drop the "BAR %d: set to %pR" message; this is mostly redundant with the "BAR %d: assigned %pR" message from pci_assign_resource(). Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-27PCI: Mark resources as IORESOURCE_UNSET if we can't assign themBjorn Helgaas4-0/+13
When assigning addresses to resources, mark them with IORESOURCE_UNSET before we start and clear IORESOURCE_UNSET if assignment is successful. That means that if we print the resource during assignment, we will show the size, not a meaningless address. Also, clear IORESOURCE_UNSET if we do assign an address, so we print the address when it is valid. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-27PCI: Remove pci_find_parent_resource() use for allocationBjorn Helgaas1-16/+23
If the resource hasn't been allocated yet, pci_find_parent_resource() is documented as returning the region "where it should be allocated from." This is impossible in general because there may be several candidates: a prefetchable BAR can be put in either a prefetchable or non-prefetchable window, a transparent bridge may have overlapping positively- and subtractively-decoded windows, and a root bus may have several windows of the same type. Allocation should be done by pci_bus_alloc_resource(), which iterates through all bus resources and looks for the best match, e.g., one with the desired prefetchability attributes, and falls back to less-desired possibilities. The only valid use of pci_find_parent_resource() is to find the parent of an already-allocated resource so we can claim it via request_resource(), and all we need for that is a bus region of the correct type that contains the resource. Note that like 8c8def26bfaa ("PCI: allow matching of prefetchable resources to non-prefetchable windows"), this depends on pci_bus_for_each_resource() iterating through positively-decoded regions before subtractively-decoded ones. We prefer not to return a subtractively-decoded region because requesting from it will likely conflict with the overlapping positively- decoded window (see Launchpad report below). Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/424142 Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Linus Torvalds <torvalds@linux-foundation.org>
2014-02-27resource: Add resource_contains()Bjorn Helgaas1-8/+0
We have two identical copies of resource_contains() already, and more places that could use it. This moves it to ioport.h where it can be shared. resource_contains(struct resource *r1, struct resource *r2) returns true iff r1 and r2 are the same type (most callers already checked this separately) and the r1 address range completely contains r2. In addition, the new resource_contains() checks that both r1 and r2 have addresses assigned to them. If a resource is IORESOURCE_UNSET, it doesn't have a valid address and can't contain or be contained by another resource. Some callers already check this or for res->start. No functional change. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-27i2o: Use pci_bus_alloc_resource(), not allocate_resource() directlyBjorn Helgaas1-10/+6
Convert i2o_res_alloc() to use pci_bus_alloc_resource() rather than pci_find_parent_resource() and allocate_resource(). We don't have a resource to start with, so pci_find_parent_resource() can't do anything useful: a bus may have several memory resources available, so there might be several possible parents. This is more likely on root buses because host bridges may have any number of apertures. I'm pretty sure this didn't work in the first place because it passed size == min == max to allocate_resource(). The min and max parameters are constraints on the *addresses* of the resource, not on its size, so I think it was impossible for allocate_resource() to succeed. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-27Merge branches 'pci/host-designware', 'pci/host-imx6' and 'pci/host-rcar' ↵Bjorn Helgaas4-78/+153
into next * pci/host-designware: PCI: designware: Fix RC BAR to be single 64-bit non-prefetchable memory BAR * pci/host-imx6: PCI: imx6: Wait for retraining * pci/host-rcar: PCI: rcar: Make the Kconfig dependencies more generic PCI: rcar: Break out window size handling PCI: rcar: Register each instance independently PCI: rcar: Fix bridge logic configuration accesses PCI: rcar: Add error interrupt handling PCI: rcar: Check platform_get_irq() return code
2014-02-27PCI: rcar: Make the Kconfig dependencies more genericMagnus Damm1-1/+1
Update the R-Car Generation 2 PCI driver Kconfig dependencies to follow same style as other drivers - no SoC dependencies. Also, update the COMPILE_TEST bits to depend on ARM. This since the DMA bounce buffer and dma_ops handling code is ARM specific. [bhelgaas: adjust context after dropping DMABOUNCE patches] Signed-off-by: Magnus Damm <damm@opensource.se> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Simon Horman <horms+renesas@verge.net.au>
2014-02-26i2o: Refactor i2o_iop_systab_set() PCI space allocationBjorn Helgaas1-43/+46
Refactor the PCI space allocation in i2o_iop_systab_set(). This might improve readability slightly, but mainly it is to make the next patch simpler. No functional change. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-26i2o: Fix I/O space alignment requirementBjorn Helgaas1-1/+1
When i2o_iop_systab_set() allocates I/O port space, it specifies 1Mb alignment required. This seems unlikely, since most platforms have only 64Kb of I/O space total. I think 4Kb is a more reasonable choice, since that's the minimum alignment of a PCI-PCI bridge I/O window. My guess is that this is a copy/paste error from the memory allocation code, which specifies 1Mb alignment (which is the minimum alignment of a PCI-PCI bridge memory window). Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-26i2o: Fix I/O space allocation copy/paste errorBjorn Helgaas1-1/+1
When i2o_iop_systab_set() allocates I/O port space, it assigns the base of the new I/O port region to sb->current_mem_base, not sb->current_io_base. This looks like a copy/paste error, because we do use current_io_base, but there's no other place that sets it. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-21Merge branch 'pci/dead-code' into nextBjorn Helgaas6-123/+4
* pci/dead-code: PCI: Remove unused SR-IOV VF Migration support iommu/amd: Add include of <linux/irqreturn.h> mei: Add include of <linux/irqreturn.h> misc: mic: Add include of <linux/irqreturn.h>
2014-02-21Merge branch 'pci/pciehp' into nextBjorn Helgaas6-75/+189
* pci/pciehp: PCI: pciehp: Cleanup whitespace PCI: pciehp: Remove a non-existent card, regardless of "surprise" capability PCI: pciehp: Don't turn slot off when hot-added device already exists PCI: pciehp: Add hotplug_lock to serialize hotplug events PCI: pciehp: Ensure very fast hotplug events are also processed PCI: pciehp: Disable link notification across slot reset PCI: pciehp: Don't check adapter or latch status while disabling PCI: pciehp: Don't disable the link permanently during removal PCI: pciehp: Enable link state change notifications PCI: pciehp: Use link change notifications for hot-plug and removal PCI: pciehp: Make check_link_active() non-static
2014-02-20PCI: pciehp: Cleanup whitespaceBjorn Helgaas3-5/+6
Minor whitespace cleanup; no functional change. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-20PCI: pciehp: Remove a non-existent card, regardless of "surprise" capabilityRajat Jain2-5/+13
In case a card is physically yanked out, it should immediately be removed, regardless of the "surprise" capability bit. Thus: - Always handle the physical removal - regardless of the "surprise" bit. - Don't use "surprise" capability when making decisions about enabling presence detect notifications. - Reword the comments to indicate the intent. Signed-off-by: Rajat Jain <rajatxjain@gmail.com> Signed-off-by: Rajat Jain <rajatjain@juniper.net> Signed-off-by: Guenter Roeck <groeck@juniper.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-20PCI: imx6: Wait for retrainingMarek Vasut1-13/+34
This patch handles the case where the PCIe link is up and running, yet drops into the LTSSM training mode. The link spends short time in the LTSSM training mode, but the current code can misinterpret it as the link being stalled. Waiting for the LTSSM training to complete fixes the issue. Quoting Sascha: This is broken since commit 7f9f40c01cce ('PCI: imx6: Report "link up" only after link training completes'). The designware driver changes the PORT_LOGIC_SPEED_CHANGE bit in dw_pcie_host_init() which causes the link to be retrained. During the next call to dw_pcie_rd_conf() the link is then reported being down and the function returns PCIBIOS_DEVICE_NOT_FOUND resulting in nonfunctioning PCIe. Fixes: 7f9f40c01cce (PCI: imx6: Report "link up" only after link training completes) Tested-by: Troy Kisky <troy.kisky@boundarydevices.com> Tested-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Shawn Guo <shawn.guo@linaro.org>
2014-02-20PCI: designware: Fix RC BAR to be single 64-bit non-prefetchable memory BARMohit Kumar1-1/+1
The Synopsys PCIe core provides one pair of 32-bit BARs (BAR 0 and BAR 1). The BARs can be configured as follows: - One 64-bit BAR: BARs 0 and 1 are combined to form a single 64-bit BAR - Two 32-bit BARs: BARs 0 and 1 are two independent 32-bit BARs This patch corrects 64-bit, non-prefetchable memory BAR configuration implemented in dw driver. Signed-off-by: Mohit Kumar <mohit.kumar@st.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Pratyush Anand <pratyush.anand@st.com> Cc: Jingoo Han <jg1.han@samsung.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: stable@vger.kernel.org # v3.12+
2014-02-19PCI: Remove unused SR-IOV VF Migration supportBjorn Helgaas2-123/+0
This reverts commit 74bb1bcc7dbb ("PCI: handle SR-IOV Virtual Function Migration"), removing this exported interface: pci_sriov_migration() Since pci_sriov_migration() is unused, it is impossible to schedule sriov_migration_task() or use any of the other migration infrastructure. This is based on Stephen Hemminger's patch (see link below), but goes a bit further. Link: http://lkml.kernel.org/r/20131227132710.7190647c@nehalam.linuxnetplumber.net Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Stephen Hemminger <stephen@networkplumber.org>
2014-02-19iommu/amd: Add include of <linux/irqreturn.h>Bjorn Helgaas1-0/+1
We currently include <linux/irqreturn.h> in <linux/pci.h>, but I'm about to remove that from linux/pci.h, so add explicit includes where needed. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-19mei: Add include of <linux/irqreturn.h>Bjorn Helgaas1-0/+1
We currently include <linux/irqreturn.h> in <linux/pci.h>, but I'm about to remove that from linux/pci.h, so add explicit includes where needed. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Tomas Winkler <tomas.winkler@intel.com>
2014-02-19Merge branch 'pci/misc' into nextBjorn Helgaas3-37/+39
* pci/misc: PCI: Enable INTx if BIOS left them disabled ia64/PCI: Set IORESOURCE_ROM_SHADOW only for the default VGA device x86/PCI: Set IORESOURCE_ROM_SHADOW only for the default VGA device PCI: Update outdated comment for pcibios_bus_report_status() PCI: Cleanup per-arch list of object files PCI: cpqphp: Fix hex vs decimal typo in cpqhpc_probe() x86/PCI: Fix function definition whitespace x86/PCI: Reword comments x86/PCI: Remove unnecessary local variable initialization PCI: Remove unnecessary list_empty(&pci_pme_list) check
2014-02-19PCI: Enable INTx if BIOS left them disabledBjorn Helgaas1-0/+10
Some firmware leaves the Interrupt Disable bit set even if the device uses INTx interrupts. Clear Interrupt Disable so we get those interrupts. Based on the report mentioned below, if the user selects the "EHCI only" option in the Intel Baytrail BIOS, the EHCI device is handed off to the OS with the PCI_COMMAND_INTX_DISABLE bit set. Link: http://lkml.kernel.org/r/20140114181721.GC12126@xanatos Link: https://bugzilla.kernel.org/show_bug.cgi?id=70601 Reported-by: Chris Cheng <chris.cheng@atrustcorp.com> Reported-and-tested-by: Jamie Chen <jamie.chen@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2014-02-19Merge branch 'pci/host-mvebu' into nextBjorn Helgaas2-13/+28
* pci/host-mvebu: PCI: mvebu: Call request_resource() on the apertures bus: mvebu-mbus: Fix incorrect size for PCI aperture resources PCI: mvebu: Fix potential issue in range parsing PCI: mvebu: Use Device ID and revision from underlying endpoint
2014-02-19Merge branch 'pci/list-for-each-entry' into nextBjorn Helgaas5-21/+22
* pci/list-for-each-entry: PCI: Remove pci_bus_b() and use list_for_each_entry() directly pcmcia: Use list_for_each_entry() for bus traversal powerpc/PCI: Use list_for_each_entry() for bus traversal drm: Use list_for_each_entry() for bus traversal ARM/PCI: Use list_for_each_entry() for bus traversal ACPI / hotplug / PCI: Use list_for_each_entry() for bus traversal
2014-02-19misc: mic: Add include of <linux/irqreturn.h>Bjorn Helgaas2-0/+2
We currently include <linux/irqreturn.h> in <linux/pci.h>, but I'm about to remove that from linux/pci.h, so add explicit includes where needed. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Sudeep Dutt <sudeep.dutt@intel.com>
2014-02-19PCI: mvebu: Call request_resource() on the aperturesJason Gunthorpe1-1/+23
It is typical for host drivers to request a resource for the aperture; once this is done the PCI core will properly populate resources for all BARs in the system. With this patch cat /proc/iomem will now show: e0000000-efffffff : PCI MEM 0000 e0000000-e00fffff : PCI Bus 0000:01 e0000000-e001ffff : 0000:01:00.0 Tested on Kirkwood. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Jason Cooper <jason@lakedaemon.net>
2014-02-19bus: mvebu-mbus: Fix incorrect size for PCI aperture resourcesJason Gunthorpe1-2/+2
reg[0] is the DT base, reg[1] is the DT length in bytes, struct resource.end is the inclusive end address, so a -1 is required. Tested on kirkwood. Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Jason Cooper <jason@lakedaemon.net> Acked-by: Arnd Bergmann <arnd@arndb.de>
2014-02-19PCI: rcar: Break out window size handlingMagnus Damm1-3/+28
Break out the hard coded window size code to allow dynamic setup. The window size is still left at 1GiB but with this patch changing window size is easy for testing. Signed-off-by: Magnus Damm <damm@opensource.se> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Simon Horman <horms+renesas@verge.net.au>
2014-02-19PCI: rcar: Register each instance independentlyMagnus Damm1-60/+20
Convert the code to allow per-device probe() like other device drivers. This also delays driver registration due to change from subsys_initcall() to regular module_platform_driver(). Signed-off-by: Magnus Damm <damm@opensource.se> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Simon Horman <horms+renesas@verge.net.au>
2014-02-19PCI: rcar: Fix bridge logic configuration accessesBen Dooks1-0/+4
The bridge logic at slot 0 only supports reads up to 0x40 and the rest of the PCI configuration space for this slot is marked as reserved in the manual. Trying a read from offset 0x100 is producing an error from the bridge. With error interrupts enabled, the following is printed: pci-rcar-gen2 ee0d0000.pci: error irq: status 00000014 Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Magnus Damm <damm@opensource.se> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Simon Horman <horms+renesas@verge.net.au>
2014-02-19PCI: rcar: Add error interrupt handlingBen Dooks1-0/+60
Add option to enable interrupts to report any errors from the AHB-PCI bridge to help find any issues with the bridge when in use. Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Magnus Damm <damm@opensource.se> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Simon Horman <horms+renesas@verge.net.au>
2014-02-19PCI: rcar: Check platform_get_irq() return codeBen Dooks1-0/+5
The current code does not check the return from platform_get_irq() so add an error check and return if this call does fail. Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Magnus Damm <damm@opensource.se> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Simon Horman <horms+renesas@verge.net.au>
2014-02-15Merge branch 'pci/msi' into nextBjorn Helgaas3-15/+25
* pci/msi: vfio: Use pci_enable_msi_range() and pci_enable_msix_range() ahci: Use pci_enable_msi_range() instead of pci_enable_msi_block() ahci: Fix broken fallback to single MSI mode PCI/MSI: Add pci_enable_msi_exact() and pci_enable_msix_exact() PCI/MSI: Fix cut-and-paste errors in documentation PCI/MSI: Add pci_enable_msi() documentation back PCI/MSI: Fix pci_msix_vec_count() htmldocs failure PCI/MSI: Fix leak of msi_attrs PCI/MSI: Check kmalloc() return value, fix leak of name
2014-02-15Merge branch 'pci/virtualization' into nextBjorn Helgaas2-6/+205
* pci/virtualization: PCI: Enable quirks for PCIe ACS on Intel PCH root ports PCI: Add pci_dev_flag for ACS enable quirks PCI: Add device-specific PCI ACS enable
2014-02-15Merge branch 'pci/scan-bridge' into nextBjorn Helgaas1-47/+29
* pci/scan-bridge: PCI: Don't scan random busses in pci_scan_bridge() PCI: Check for child busses which use more bus numbers than allocated PCI: Remove pci_fixup_parent_subordinate_busnr() PCI: Make sure bus number resources stay within their parents bounds PCI: Use request_resource_conflict() instead of insert_ for bus numbers PCI: Assign CardBus bus number only during the second pass PCI: Clarify the "scan anyway" comment in pci_scan_bridge() PCI: Increment max correctly in pci_scan_bridge()
2014-02-15vfio: Use pci_enable_msi_range() and pci_enable_msix_range()Alexander Gordeev1-4/+8
pci_enable_msix() and pci_enable_msi_block() have been deprecated; use pci_enable_msix_range() and pci_enable_msi_range() instead. [bhelgaas: changelog] Signed-off-by: Alexander Gordeev <agordeev@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Alex Williamson <alex.williamson@redhat.com>
2014-02-15ahci: Use pci_enable_msi_range() instead of pci_enable_msi_block()Alexander Gordeev1-11/+9
pci_enable_msi_block() has been deprecated; use pci_enable_msi_range() instead. [bhelgaas: changelog] Signed-off-by: Alexander Gordeev <agordeev@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Tejun Heo <tj@kernel.org>
2014-02-15ahci: Fix broken fallback to single MSI modeAlexander Gordeev1-1/+3
Commit 7b92b4f61ec4 ("PCI/MSI: Remove pci_enable_msi_block_auto()") introduced a regression: if multiple MSI initialization fails, the code falls back to INTx rather than to single MSI. Fixes: 7b92b4f61ec4 ("PCI/MSI: Remove pci_enable_msi_block_auto()") Signed-off-by: Alexander Gordeev <agordeev@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Tejun Heo <tj@kernel.org>
2014-02-14PCI: Remove pci_bus_b() and use list_for_each_entry() directlyYijing Wang2-8/+8
Replace list_for_each() with list_for_each_entry(), which means we no longer need pci_bus_b() and can remove it. Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-02-05 21:01:26 +0300