summaryrefslogtreecommitdiffstats
path: root/drivers/pci
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'core-iommu-for-linus' of ↵Linus Torvalds2009-12-052-4/+9
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'core-iommu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: (63 commits) x86, Calgary IOMMU quirk: Find nearest matching Calgary while walking up the PCI tree x86/amd-iommu: Remove amd_iommu_pd_table x86/amd-iommu: Move reset_iommu_command_buffer out of locked code x86/amd-iommu: Cleanup DTE flushing code x86/amd-iommu: Introduce iommu_flush_device() function x86/amd-iommu: Cleanup attach/detach_device code x86/amd-iommu: Keep devices per domain in a list x86/amd-iommu: Add device bind reference counting x86/amd-iommu: Use dev->arch->iommu to store iommu related information x86/amd-iommu: Remove support for domain sharing x86/amd-iommu: Rearrange dma_ops related functions x86/amd-iommu: Move some pte allocation functions in the right section x86/amd-iommu: Remove iommu parameter from dma_ops_domain_alloc x86/amd-iommu: Use get_device_id and check_device where appropriate x86/amd-iommu: Move find_protection_domain to helper functions x86/amd-iommu: Simplify get_device_resources() x86/amd-iommu: Let domain_for_device handle aliases x86/amd-iommu: Remove iommu specific handling from dma_ops path x86/amd-iommu: Remove iommu parameter from __(un)map_single x86/amd-iommu: Make alloc_new_range aware of multiple IOMMUs ...
| * Merge commit 'v2.6.32-rc7' into core/iommuIngo Molnar2009-11-171-2/+4
| |\ | | | | | | | | | | | | | | | Merge reason: Add fixes we'll depend on. Signed-off-by: Ingo Molnar <mingo@elte.hu>
| * | x86: Handle HW IOMMU initialization failure gracefullyFUJITA Tomonori2009-11-102-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If HW IOMMU initialization fails (Intel VT-d often does this, typically due to BIOS bugs), we fall back to nommu. It doesn't work for the majority since nowadays we have more than 4GB memory so we must use swiotlb instead of nommu. The problem is that it's too late to initialize swiotlb when HW IOMMU initialization fails. We need to allocate swiotlb memory earlier from bootmem allocator. Chris explained the issue in detail: http://marc.info/?l=linux-kernel&m=125657444317079&w=2 The current x86 IOMMU initialization sequence is too complicated and handling the above issue makes it more hacky. This patch changes x86 IOMMU initialization sequence to handle the above issue cleanly. The new x86 IOMMU initialization sequence are: 1. we initialize the swiotlb (and setting swiotlb to 1) in the case of (max_pfn > MAX_DMA32_PFN && !no_iommu). dma_ops is set to swiotlb_dma_ops or nommu_dma_ops. if swiotlb usage is forced by the boot option, we finish here. 2. we call the detection functions of all the IOMMUs 3. the detection function sets x86_init.iommu.iommu_init to the IOMMU initialization function (so we can avoid calling the initialization functions of all the IOMMUs needlessly). 4. if the IOMMU initialization function doesn't need to swiotlb then sets swiotlb to zero (e.g. the initialization is sucessful). 5. if we find that swiotlb is set to zero, we free swiotlb resource. Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: chrisw@sous-sol.org Cc: dwmw2@infradead.org Cc: joerg.roedel@amd.com Cc: muli@il.ibm.com LKML-Reference: <1257849980-22640-10-git-send-email-fujita.tomonori@lab.ntt.co.jp> Signed-off-by: Ingo Molnar <mingo@elte.hu>
| * | x86: intel-iommu: Convert detect_intel_iommu to use iommu_init hookFUJITA Tomonori2009-11-101-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changes detect_intel_iommu() to set intel_iommu_init() to iommu_init hook if detect_intel_iommu() finds the IOMMU. Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: chrisw@sous-sol.org Cc: dwmw2@infradead.org Cc: joerg.roedel@amd.com Cc: muli@il.ibm.com LKML-Reference: <1257849980-22640-6-git-send-email-fujita.tomonori@lab.ntt.co.jp> [ -v2: build fix for the !CONFIG_DMAR case ] Signed-off-by: Ingo Molnar <mingo@elte.hu>
* | | Fix handling of the HP/Acer 'DMAR at zero' BIOS error for machines with ↵David Woodhouse2009-11-191-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | <4GiB RAM. Commit 86cf898e1d0fca245173980e3897580db38569a8 ("intel-iommu: Check for 'DMAR at zero' BIOS error earlier.") was supposed to work by pretending not to detect an IOMMU if it was actually being reported by the BIOS at physical address zero. However, the intel_iommu_init() function is called unconditionally, as are the corresponding functions for other IOMMU hardware. So the patch only worked if you have RAM above the 4GiB boundary. It caused swiotlb to be initialised when no IOMMU was detected during early boot, and thus the later IOMMU init would refuse to run. But if you have less RAM than that, swiotlb wouldn't get set up and the IOMMU _would_ still end up being initialised, even though we never claimed to detect it. This patch also sets the dmar_disabled flag when the error is detected during the initial detection phase -- so that the later call to intel_iommu_init() will return without doing anything, regardless of whether swiotlb is used or not. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | | Merge git://git.infradead.org/users/dwmw2/iommu-2.6.32Linus Torvalds2009-11-142-11/+77
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | * git://git.infradead.org/users/dwmw2/iommu-2.6.32: intel-iommu: Support PCIe hot-plug intel-iommu: Obey coherent_dma_mask for alloc_coherent on passthrough intel-iommu: Check for 'DMAR at zero' BIOS error earlier.
| * | intel-iommu: Support PCIe hot-plugFenghua Yu2009-11-121-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To support PCIe hot plug in IOMMU, we register a notifier to respond to device change action. When the notifier gets BUS_NOTIFY_UNBOUND_DRIVER, it removes the device from its DMAR domain. A hot added device will be added into an IOMMU domain when it first does IOMMU op. So there is no need to add more code for hot add. Without the patch, after a hot-remove, a hot-added device on the same slot will not work. Signed-off-by: Fenghua Yu <fenghua.yu@intel.com> Tested-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * | intel-iommu: Obey coherent_dma_mask for alloc_coherent on passthroughAlex Williamson2009-11-121-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The model for IOMMU passthrough is that decent devices that can cope with DMA to all of memory get passthrough; crappy devices with a limited dma_mask don't -- they get to use the IOMMU anyway. This is done on the basis that IOMMU passthrough is usually wanted for performance reasons, and it's only the decent PCI devices that you really care about performance for, while the crappy 32-bit ones like your USB controller can just use the IOMMU and you won't really care. Unfortunately, the check for this was only looking at dev->dma_mask, not at dev->coherent_dma_mask. And some devices have a 32-bit coherent_dma_mask even though they have a full 64-bit dma_mask. Even more unfortunately, fixing that simple oversight would upset certain broken HP devices. Not only do they have a 32-bit coherent_dma_mask, but they also have a tendency to do stray DMA to unmapped addresses. And then they die when they take the DMA fault they so richly deserve. So if we do the 'correct' fix, it'll mean that affected users have to disable IOMMU support completely on "a large percentage of servers from a major vendor." Personally, I have little sympathy -- given that this is the _same_ 'major vendor' who is shipping machines which claim to have IOMMU support but have obviously never _once_ booted a VT-d capable OS to do any form of QA. But strictly speaking, it _would_ be a regression even though it only ever worked by fluke. For 2.6.33, we'll come up with a quirk which gives swiotlb support for this particular device, and other devices with an inadequate coherent_dma_mask will just get normal IOMMU mapping. The simplest fix for 2.6.32, though, is just to jump through some hoops to try to allocate coherent DMA memory for such devices in a place that they can reach. We'd use dma_generic_alloc_coherent() for this if it existed on IA64. Signed-off-by: Alex Williamson <alex.williamson@hp.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * | intel-iommu: Check for 'DMAR at zero' BIOS error earlier.David Woodhouse2009-11-091-10/+39
| |/ | | | | | | | | | | | | | | | | | | | | | | | | Chris Wright has some patches which let us fall back to swiotlb nicely if IOMMU initialisation fails. But those are a bit much for 2.6.32. Instead, let's shift the check for the biggest problem, the HP and Acer BIOS bug which reports a DMAR at physical address zero. That one can actually be checked much earlier -- before we even admit to having detected an IOMMU in the first place. So the swiotlb init goes ahead as we want. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
* | PCI ASPM: fix oops on root port removalKenji Kaneshige2009-11-061-2/+4
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix the following BUG_ON() problem reported by Alex Chiang. This problem happened when removing PCIe root port using PCI logical hotplug operation. The immediate cause of this problem is that the pointer to invalid data structure is passed to pcie_update_aspm_capable() by pcie_aspm_exit_link_state(). When pcie_aspm_exit_link_state() received a pointer to root port link, it unconfigures the root port link and frees its data structure at first. At this point, there are not links to configure under the root port and the data structure for root port link is already freed. So pcie_aspm_exit_link_state() must not call pcie_update_aspm_capable() and pcie_config_aspm_path(). This patch fixes the problem by changing pcie_aspm_exit_link_state() not to call pcie_update_aspm_capable() and pcie_config_aspm_path() if the specified link is root port link. ------------[ cut here ]------------ kernel BUG at drivers/pci/pcie/aspm.c:606! invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC last sysfs file: /sys/devices/pci0000:40/0000:40:13.0/remove CPU 1 Modules linked in: shpchp Pid: 9345, comm: sysfsd Not tainted 2.6.32-rc5 #98 ProLiant DL785 G6 RIP: 0010:[<ffffffff811df69b>] [<ffffffff811df69b>] pcie_update_aspm_capable+0x15/0xbe RSP: 0018:ffff88082a2f5ca0 EFLAGS: 00010202 RAX: 0000000000000e77 RBX: ffff88182cc3e000 RCX: ffff88082a33d006 RDX: 0000000000000001 RSI: ffffffff811dff4a RDI: ffff88182cc3e000 RBP: ffff88082a2f5cc0 R08: ffff88182cc3e000 R09: 0000000000000000 R10: ffff88182fc00180 R11: ffff88182fc00198 R12: ffff88182cc3e000 R13: 0000000000000000 R14: ffff88182cc3e000 R15: ffff88082a2f5e20 FS: 00007f259a64b6f0(0000) GS:ffff880864600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 00007feb53f73da0 CR3: 000000102cc94000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process sysfsd (pid: 9345, threadinfo ffff88082a2f4000, task ffff88082a33cf00) Stack: ffff88182cc3e000 ffff88182cc3e000 0000000000000000 ffff88082a33cf00 <0> ffff88082a2f5cf0 ffffffff811dff52 ffff88082a2f5cf0 ffff88082c525168 <0> ffff88402c9fd2f8 ffff88402c9fd2f8 ffff88082a2f5d20 ffffffff811d7db2 Call Trace: [<ffffffff811dff52>] pcie_aspm_exit_link_state+0xf5/0x11e [<ffffffff811d7db2>] pci_stop_bus_device+0x76/0x7e [<ffffffff811d7d67>] pci_stop_bus_device+0x2b/0x7e [<ffffffff811d7e4f>] pci_remove_bus_device+0x15/0xb9 [<ffffffff811dcb8c>] remove_callback+0x29/0x3a [<ffffffff81135aeb>] sysfs_schedule_callback_work+0x15/0x6d [<ffffffff81072790>] worker_thread+0x19d/0x298 [<ffffffff8107273b>] ? worker_thread+0x148/0x298 [<ffffffff81135ad6>] ? sysfs_schedule_callback_work+0x0/0x6d [<ffffffff810765c0>] ? autoremove_wake_function+0x0/0x38 [<ffffffff810725f3>] ? worker_thread+0x0/0x298 [<ffffffff8107629e>] kthread+0x7d/0x85 [<ffffffff8102eafa>] child_rip+0xa/0x20 [<ffffffff8102e4bc>] ? restore_args+0x0/0x30 [<ffffffff81076221>] ? kthread+0x0/0x85 [<ffffffff8102eaf0>] ? child_rip+0x0/0x20 Code: 89 e5 8a 50 48 31 c0 c0 ea 03 83 e2 07 e8 b2 de fe ff c9 48 98 c3 55 48 89 e5 41 56 49 89 fe 41 55 41 54 53 48 83 7f 10 00 74 04 <0f> 0b eb fe 48 8b 05 da 7d 63 00 4c 8d 60 e8 4c 89 e1 eb 24 4c RIP [<ffffffff811df69b>] pcie_update_aspm_capable+0x15/0xbe RSP <ffff88082a2f5ca0> ---[ end trace 6ae0f65bdeab8555 ]--- Reported-by: Alex Chiang <achiang@hp.com> Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Tested-by: Alex Chiang <achiang@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* Revert "PCI: get larger bridge ranges when space is available"Jesse Barnes2009-10-271-11/+2
| | | | | | | | This reverts commit 308cf8e13f42f476dfd6552aeff58fdc0788e566. This patch had trouble with transparent bridges, among other things. A more readable and correct version should land in 2.6.33. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* ahci / atiixp / pci quirks: rename AMD SB900 into Hudson-2Shane Huang2009-10-161-3/+3
| | | | | | | This patch renames the code name SB900 into Hudson-2 Signed-off-by: Shane Huang <shane.huang@amd.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
* headers: Fix build after <linux/sched.h> removalIngo Molnar2009-10-131-0/+1
| | | | | | | | | | Commit d43c36dc6b357fa1806800f18aa30123c747a6d1 ("headers: remove sched.h from interrupt.h") left some build errors in some configurations due to drivers having depended on getting header files "accidentally". Signed-off-by: Ingo Molnar <mingo@elte.hu> [ Combined several one-liners from Ingo into one single patch - Linus ] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Merge git://git.infradead.org/~dwmw2/iommu-2.6.32Linus Torvalds2009-10-134-19/+102
|\ | | | | | | | | | | | | | | | | | | | | * git://git.infradead.org/~dwmw2/iommu-2.6.32: x86: Move pci_iommu_init to rootfs_initcall() Run pci_apply_final_quirks() sooner. Mark pci_apply_final_quirks() __init rather than __devinit Rename pci_init() to pci_apply_final_quirks(), move it to quirks.c intel-iommu: Yet another BIOS workaround: Isoch DMAR unit with no TLB space intel-iommu: Decode (and ignore) RHSA entries intel-iommu: Make "Unknown DMAR structure" message more informative
| * Run pci_apply_final_quirks() sooner.David Woodhouse2009-10-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Having this as a device_initcall() means that some real device drivers can actually initialise _before_ the quirks are run, which is wrong. We want it to run _before_ device_initcall(), but _after_ fs_initcall(), since some arch-specific PCI initialisation like pcibios_assign_resources() is done at fs_initcall(). We could use rootfs_initcall() but I actually want to use that for the IOMMU initialisation, which has to come after the quirks, but still before the real devices. So use fs_initcall_sync() instead -- since this is entirely synchronous, it doesn't hurt that it'll escape the synchronisation. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * Mark pci_apply_final_quirks() __init rather than __devinitDavid Woodhouse2009-10-121-1/+1
| | | | | | | | | | | | It doesn't get invoked on hotplug; it can be thrown away after init. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * Rename pci_init() to pci_apply_final_quirks(), move it to quirks.cDavid Woodhouse2009-10-122-13/+13
| | | | | | | | | | | | | | | | This function may have done more in the past, but all it does now is apply the PCI_FIXUP_FINAL quirks. So name it sensibly and put it where it belongs. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * intel-iommu: Yet another BIOS workaround: Isoch DMAR unit with no TLB spaceDavid Woodhouse2009-09-301-5/+77
| | | | | | | | | | | | | | | | | | Asus decided to ship a BIOS which configures sound DMA to go via the dedicated IOMMU unit, but assigns precisely zero TLB entries to that unit. Which causes the whole thing to deadlock, including the DMA traffic on the _other_ IOMMU units. Nice one. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * intel-iommu: Decode (and ignore) RHSA entriesRoland Dreier2009-09-241-0/+10
| | | | | | | | | | | | | | | | | | | | I recently got a system where the DMAR table included a couple of RHSA (remapping hardware static affinity) entries. Rather than printing a message about an "Unknown DMAR structure," it would probably be more useful to dump the RHSA structure (as other DMAR structures are dumped). Signed-off-by: Roland Dreier <rolandd@cisco.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * intel-iommu: Make "Unknown DMAR structure" message more informativeRoland Dreier2009-09-231-1/+2
| | | | | | | | | | | | | | | | | | | | We might as well print the type of the DMAR structure we don't know how to handle when skipping it. Then someone getting this message has a chance of telling whether the structure is just bogus, or if there really is something valid that the kernel doesn't know how to handle. Signed-off-by: Roland Dreier <rolandd@cisco.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
* | Merge branch 'for-linus' of ↵Linus Torvalds2009-10-126-47/+41
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6 * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6: PCI: Prevent AER driver from being loaded on non-root port PCIE devices PCI: get larger bridge ranges when space is available PCI: pci.c: fix kernel-doc notation PCI quirk: TI XIO200a erroneously reports support for fast b2b transfers PCI PM: Read device power state from register after updating it PCI: remove pci_assign_resource_fixed() PCI: PCIe portdrv: remove "-driver" from driver name
| * | PCI: Prevent AER driver from being loaded on non-root port PCIE devicesKenji Kaneshige2009-10-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A bug was seen on boards using a PLX 8518 switch device which advertises AER on each of it's transparent bridges. The AER driver was loaded for each bridge and this driver tried to access the AER source ID register whenever an interrupt occured on the shared PCI INTX lines. The source ID register does not exist on non root port PCIE device's which advertise AER and trying to access this register causes a unsupported request error on the bridge. Thus, when the next interrupt occurs, another error is found and the non existent source ID register is accessed again, and so it goes on. The result is a spammed dmesg with unsupported request PCI express errors on the bridge device that the AER driver is loaded against. Reported-by: Malcolm Crossley <malcolm.crossley2@gefanuc.com> Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Tested-by: Malcolm Crossley <malcolm.crossley2@gefanuc.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * | PCI: get larger bridge ranges when space is availableYinghai Lu2009-10-071-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Found one system: [ 71.120590] pci 0000:40:05.0: scanning behind bridge, config 4f4a40, pass 0 [ 71.138283] PCI: Scanning bus 0000:4a [ 71.140341] pci 0000:4a:00.0: found [15b3:6278] class 000c06 header type 00 [ 71.157173] pci 0000:4a:00.0: reg 10 64bit mmio: [0x000000-0x0fffff] [ 71.161697] pci 0000:4a:00.0: reg 18 64bit mmio pref: [0x000000-0x7fffff] [ 71.179403] pci 0000:4a:00.0: reg 20 64bit mmio pref: [0x000000-0xfffffff] [ 71.185366] pci 0000:4a:00.0: calling quirk_resource_alignment+0x0/0x1dd [ 71.200846] pci 0000:4a:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' [ 71.219623] PCI: Fixups for bus 0000:4a [ 71.222194] pci 0000:40:05.0: bridge 32bit mmio: [0xcf000000-0xcf0fffff] [ 71.238662] pci 0000:40:05.0: bridge 64bit mmio pref: [0xcd800000-0xcdffffff] [ 71.255793] PCI: Bus scan for 0000:4a returning with max=4a Device needs a big pref mmio, but BIOS doesn't allocate mmio to it aside from a small MMIO range. Later, the kernel will not allocate resources to that to the device: [ 99.574030] pci 0000:4a:00.0: BAR 4: can't allocate mem resource [0xd0000000-0xcdffffff] [ 99.580102] pci 0000:4a:00.0: BAR 2: got res [0xcd800000-0xcdffffff] bus [0xcd800000-0xcdffffff] flags 0x12120c [ 99.602307] pci 0000:4a:00.0: BAR 2: moved to bus [0xcd800000-0xcdffffff] flags 0x12120c [ 99.615991] pci 0000:4a:00.0: BAR 0: got res [0xcf000000-0xcf0fffff] bus [0xcf000000-0xcf0fffff] flags 0x120204 [ 99.634499] pci 0000:4a:00.0: BAR 0: moved to bus [0xcf000000-0xcf0fffff] flags 0x120204 [ 99.654318] pci 0000:40:05.0: PCI bridge, secondary bus 0000:4a [ 99.658766] pci 0000:40:05.0: IO window: disabled [ 99.675478] pci 0000:40:05.0: MEM window: 0xcf000000-0xcf0fffff [ 99.681663] pci 0000:40:05.0: PREFETCH window: 0x000000cd800000-0x000000cdffffff So try to get a big range in the pci bridge if there is no child using that range. With the patch we get: [ 99.104525] pci 0000:4a:00.0: BAR 4: got res [0xfc080000000-0xfc08fffffff] bus [0xfc080000000-0xfc08fffffff] flags 0x12120c [ 99.123624] pci 0000:4a:00.0: BAR 4: moved to bus [0xfc080000000-0xfc08fffffff] flags 0x12120c [ 99.131977] pci 0000:4a:00.0: BAR 2: got res [0xfc090000000-0xfc0907fffff] bus [0xfc090000000-0xfc0907fffff] flags 0x12120c [ 99.149788] pci 0000:4a:00.0: BAR 2: moved to bus [0xfc090000000-0xfc0907fffff] flags 0x12120c [ 99.169248] pci 0000:4a:00.0: BAR 0: got res [0xc0200000-0xc02fffff] bus [0xc0200000-0xc02fffff] flags 0x120204 [ 99.189508] pci 0000:4a:00.0: BAR 0: moved to bus [0xc0200000-0xc02fffff] flags 0x120204 [ 99.206402] pci 0000:40:05.0: PCI bridge, secondary bus 0000:4a [ 99.210637] pci 0000:40:05.0: IO window: disabled [ 99.224856] pci 0000:40:05.0: MEM window: 0xc0200000-0xc03fffff [ 99.230019] pci 0000:40:05.0: PREFETCH window: 0x000fc080000000-0x000fc097ffffff Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * | PCI: pci.c: fix kernel-doc notationRandy Dunlap2009-10-071-4/+4
| | | | | | | | | | | | | | | | | | | | | Fix kernel-doc notation (& warnings) in pci/pci.c. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * | PCI quirk: TI XIO200a erroneously reports support for fast b2b transfersGabe Black2009-10-071-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | This quirk will disable fast back to back transfer on the secondary bus segment of the TI Bridge. Signed-off-by: Gabe Black <gabe.black@ni.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * | PCI PM: Read device power state from register after updating itRafael J. Wysocki2009-10-061-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After attempting to change the power state of a PCI device pci_raw_set_power_state() doesn't check if the value it wrote into the device's PCI_PM_CTRL register has been stored in there, but unconditionally modifies the device's current_state field to reflect the change. This may cause problems to happen if the power state of the device hasn't been changed in fact, because it will make the PCI PM core make a wrong assumption. To prevent such situations from happening modify pci_raw_set_power_state() so that it reads the device's PCI_PM_CTRL register after writing into it and uses the value read from the register to update the device's current_state field. Also make it print a message saying that the device refused to change its power state as requested (returning an error code in such cases would cause suspend regressions to appear on some systems, where device drivers' suspend routines return error codes if pci_set_power_state() fails). Reviewed-by: Alex Chiang <achiang@hp.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * | PCI: remove pci_assign_resource_fixed()Bjorn Helgaas2009-10-061-37/+0
| | | | | | | | | | | | | | | | | | | | | | | | Adrian commented out this function in 2baad5f96b49, but I don't think it's even worth cluttering the file with the unused code. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * | PCI: PCIe portdrv: remove "-driver" from driver nameBjorn Helgaas2009-10-061-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | No need to include "-driver" in the driver name. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> CC: Tom Long Nguyen <tom.l.nguyen@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* | | headers: remove sched.h from interrupt.hAlexey Dobriyan2009-10-111-0/+1
|/ / | | | | | | | | | | | | | | After m68k's task_thread_info() doesn't refer to current, it's possible to remove sched.h from interrupt.h and not break m68k! Many thanks to Heiko Carstens for allowing this. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
* | ACPICA: fixup after acpi_get_object_info() changeBjorn Helgaas2009-09-251-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 15b8dd53f5ffa changed info->hardware_id from a static array to a pointer. If hardware_id is non-NULL, it points to a NULL-terminated string, so we don't need to terminate it explicitly. However, it may be NULL; in that case, we *can't* add a NULL terminator. This causes a NULL pointer dereference oops for devices without _HID. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> CC: Lin Ming <ming.m.lin@intel.com> CC: Bob Moore <robert.moore@intel.com> CC: Gary Hade <garyhade@us.ibm.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | Merge branch 'linux-next' of ↵Linus Torvalds2009-09-248-314/+192
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6 * 'linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6: (21 commits) x86/PCI: make 32 bit NUMA node array int, not unsigned char x86/PCI: default pcibus cpumask to all cpus if it lacks affinity MAINTAINTERS: remove hotplug driver entries PCI: pciehp: remove slot capabilities definitions PCI: pciehp: remove error message definitions PCI: pciehp: remove number field PCI: pciehp: remove hpc_ops PCI: pciehp: remove pci_dev field PCI: pciehp: remove crit_sect mutex PCI: pciehp: remove slot_bus field PCI: pciehp: remove first_slot field PCI: pciehp: remove slot_device_offset field PCI: pciehp: remove hp_slot field PCI: pciehp: remove device field PCI: pciehp: remove bus field PCI: pciehp: remove slot_num_inc field PCI: pciehp: remove num_slots field PCI: pciehp: remove slot_list field PCI: fix VGA arbiter header file PCI: Disable AER with pci=nomsi ... Fixed up trivial conflicts in MAINTAINERS
| * PCI: pciehp: remove slot capabilities definitionsKenji Kaneshige2009-09-171-18/+8
| | | | | | | | | | | | | | | | | | Use generic PCIe slot capabilities register definitions instead of internal definitions. Acked-by: Alex Chiang <achiang@hp.com> Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI: pciehp: remove error message definitionsKenji Kaneshige2009-09-172-12/+1
| | | | | | | | | | | | | | | | Remove (almost) unused error message definitions. Acked-by: Alex Chiang <achiang@hp.com> Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI: pciehp: remove number fieldKenji Kaneshige2009-09-173-4/+2
| | | | | | | | | | | | | | | | | | Since slot_cap field in struct controller contains physical slot number informationq, we don't need number field in struct slot. Acked-by: Alex Chiang <achiang@hp.com> Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI: pciehp: remove hpc_opsKenji Kaneshige2009-09-175-118/+87
| | | | | | | | | | | | | | | | | | | | The struct hpc_ops seems a set of hooks to controller specific routines. But, it is meaningless because no hotplug controller driver follows this framework. Acked-by: Alex Chiang <achiang@hp.com> Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI: pciehp: remove pci_dev fieldKenji Kaneshige2009-09-175-17/+15
| | | | | | | | | | | | | | | | | | Since we have a pointer to pcie_device in struct controller, we don't need a pointer to pci_dev. Acked-by: Alex Chiang <achiang@hp.com> Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI: pciehp: remove crit_sect mutexKenji Kaneshige2009-09-173-16/+0
| | | | | | | | | | | | | | | | | | | | | | The crit_sect mutex defined in struct controller is to serialize hot-plug operations against multiple slots under the same bus. But, since PCIe doesnstream port has only one slot at most, it is meaningless and we don't need it. Acked-by: Alex Chiang <achiang@hp.com> Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI: pciehp: remove slot_bus fieldKenji Kaneshige2009-09-171-1/+0
| | | | | | | | | | | | | | | | Remove unused slot_bus field in struct controller. Acked-by: Alex Chiang <achiang@hp.com> Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI: pciehp: remove first_slot fieldKenji Kaneshige2009-09-172-4/+3
| | | | | | | | | | | | | | | | | | | | The slot number can be calculated only by physical slot number field in the slot capabilities register. So the first_slot field in struct controller is meaningless and we don't need it. Acked-by: Alex Chiang <achiang@hp.com> Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI: pciehp: remove slot_device_offset fieldKenji Kaneshige2009-09-174-9/+2
| | | | | | | | | | | | | | | | | | | | Since the device number of the hot-slot under the PCIe downstream port is always 0, the slot_device_offset field in the slot is meaningless and we don't need it. Acked-by: Alex Chiang <achiang@hp.com> Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI: pciehp: remove hp_slot fieldKenji Kaneshige2009-09-174-12/+4
| | | | | | | | | | | | | | | | | | | | The hp_slot field is to identify the slot under the same controller. But, since PCIe downstream port has only one slot at most, it is meaningless and we don't need it. Acked-by: Alex Chiang <achiang@hp.com> Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI: pciehp: remove device fieldKenji Kaneshige2009-09-175-28/+17
| | | | | | | | | | | | | | | | | | The device field in the struct slot is not necessary because it is always 0 in pciehp driver. Acked-by: Alex Chiang <achiang@hp.com> Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI: pciehp: remove bus fieldKenji Kaneshige2009-09-175-7/+10
| | | | | | | | | | | | | | | | The bus field in struct slot is not necessary. Acked-by: Alex Chiang <achiang@hp.com> Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI: pciehp: remove slot_num_inc fieldKenji Kaneshige2009-09-171-1/+0
| | | | | | | | | | | | | | | | | | The slot_num_inc field in struct controller is unused and meaningless in pciehp driver. Acked-by: Alex Chiang <achiang@hp.com> Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI: pciehp: remove num_slots fieldKenji Kaneshige2009-09-172-2/+0
| | | | | | | | | | | | | | | | | | | | Since PCIe downstream port has only one slot at most, we don't need num_slots field in struct controller. Note that struct controller itself doesn't exist if PCIe downstream port has no slot. Acked-by: Alex Chiang <achiang@hp.com> Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI: pciehp: remove slot_list fieldKenji Kaneshige2009-09-174-97/+76
| | | | | | | | | | | | | | | | | | Since PCIe downstream port has only one slot at most, we don't need 'slot_list' linked list to manage multiple slots under the port. Acked-by: Alex Chiang <achiang@hp.com> Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI: Disable AER with pci=nomsiAndi Kleen2009-09-171-0/+2
| | | | | | | | | | | | | | | | | | | | | | When booting with pci=nomsi aer causes lost interrupts and lockdep inversions. So check if MSIs are not disabled before initializing the aer driver. Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI ASPM: support L1 onlyKenji Kaneshige2009-09-171-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The definition of the ASPM support field in the Link Capabilities Register had been changed by the "ASPM optionality ECN" as follows: <Before> 00b Reserved 01b L0s Supported 10b Reserved 11b L0s and L1 Supported <After> 00b No ASPM Support 01b L0s Supported 10b L1 Supported 11b L0s and L1 Supported Current linux ASPM driver doesn't enable ASPM if the support field is 00b or 10b. So there is no impact about 00b. But current linux ASPM driver doesn't enable L1 if the support field is 10b. With this patch, 10b (L1 support) is handled properly. Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* | Merge git://git.infradead.org/iommu-2.6Linus Torvalds2009-09-234-182/+202
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * git://git.infradead.org/iommu-2.6: (23 commits) intel-iommu: Disable PMRs after we enable translation, not before intel-iommu: Kill DMAR_BROKEN_GFX_WA option. intel-iommu: Fix integer wrap on 32 bit kernels intel-iommu: Fix integer overflow in dma_pte_{clear_range,free_pagetable}() intel-iommu: Limit DOMAIN_MAX_PFN to fit in an 'unsigned long' intel-iommu: Fix kernel hang if interrupt remapping disabled in BIOS intel-iommu: Disallow interrupt remapping if not all ioapics covered intel-iommu: include linux/dmi.h to use dmi_ routines pci/dmar: correct off-by-one error in dmar_fault() intel-iommu: Cope with yet another BIOS screwup causing crashes intel-iommu: iommu init error path bug fixes intel-iommu: Mark functions with __init USB: Work around BIOS bugs by quiescing USB controllers earlier ia64: IOMMU passthrough mode shouldn't trigger swiotlb init intel-iommu: make domain_add_dev_info() call domain_context_mapping() intel-iommu: Unify hardware and software passthrough support intel-iommu: Cope with broken HP DC7900 BIOS iommu=pt is a valid early param intel-iommu: double kfree() intel-iommu: Kill pointless intel_unmap_single() function ... Fixed up trivial include lines conflict in drivers/pci/intel-iommu.c
| * | intel-iommu: Disable PMRs after we enable translation, not beforeDavid Woodhouse2009-09-191-2/+3
| | | | | | | | | | | | Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
OpenPOWER on IntegriCloud