Commit Graph

1980 Commits

Author SHA1 Message Date
Linus Torvalds
7b626acb8f Merge branch 'core-iommu-for-linus' of 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
  ...
2009-12-05 09:49:07 -08:00
David Woodhouse
5854d9c8d1 Fix handling of the HP/Acer 'DMAR at zero' BIOS error for machines with <4GiB RAM.
Commit 86cf898e1d ("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>
2009-11-19 13:42:02 -08:00
Ingo Molnar
99f4c9de2b Merge commit 'v2.6.32-rc7' into core/iommu
Merge reason: Add fixes we'll depend on.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-11-17 07:51:07 +01:00
Linus Torvalds
a9366e61b0 Merge git://git.infradead.org/users/dwmw2/iommu-2.6.32
* 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.
2009-11-14 13:05:27 -08:00
Fenghua Yu
99dcadede4 intel-iommu: Support PCIe hot-plug
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>
2009-11-12 02:28:45 +00:00
Alex Williamson
e8bb910d1b intel-iommu: Obey coherent_dma_mask for alloc_coherent on passthrough
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>
2009-11-12 02:10:34 +00:00
FUJITA Tomonori
75f1cdf1dd x86: Handle HW IOMMU initialization failure gracefully
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>
2009-11-10 12:32:07 +01:00
FUJITA Tomonori
9d5ce73a64 x86: intel-iommu: Convert detect_intel_iommu to use iommu_init hook
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>
2009-11-10 12:31:36 +01:00
David Woodhouse
86cf898e1d intel-iommu: Check for 'DMAR at zero' BIOS error earlier.
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>
2009-11-09 22:15:15 +00:00
Kenji Kaneshige
761434a318 PCI ASPM: fix oops on root port removal
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>
2009-11-06 14:01:23 -08:00
Jesse Barnes
55a1098476 Revert "PCI: get larger bridge ranges when space is available"
This reverts commit 308cf8e13f.  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>
2009-10-27 09:39:18 -07:00
Shane Huang
5deab53665 ahci / atiixp / pci quirks: rename AMD SB900 into Hudson-2
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>
2009-10-16 06:21:20 -04:00
Ingo Molnar
86ae13b006 headers: Fix build after <linux/sched.h> removal
Commit d43c36dc6b ("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>
2009-10-13 10:20:16 -07:00
Linus Torvalds
80fa680d22 Merge git://git.infradead.org/~dwmw2/iommu-2.6.32
* 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
2009-10-13 10:04:40 -07:00
Linus Torvalds
2caa731819 Merge branch 'for-linus' of 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
2009-10-12 14:38:34 -07:00
David Woodhouse
cf6f3bf7e5 Run pci_apply_final_quirks() sooner.
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>
2009-10-12 14:42:09 +01:00
David Woodhouse
0001026884 Mark pci_apply_final_quirks() __init rather than __devinit
It doesn't get invoked on hotplug; it can be thrown away after init.

Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2009-10-12 14:42:06 +01:00
David Woodhouse
8d86fb2c80 Rename pci_init() to pci_apply_final_quirks(), move it to quirks.c
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>
2009-10-12 14:42:04 +01:00
Alexey Dobriyan
d43c36dc6b headers: remove sched.h from interrupt.h
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>
2009-10-11 11:20:58 -07:00
Kenji Kaneshige
30fc24b5cb PCI: Prevent AER driver from being loaded on non-root port PCIE devices
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>
2009-10-07 09:28:56 -07:00
Yinghai Lu
308cf8e13f PCI: get larger bridge ranges when space is available
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>
2009-10-07 09:28:18 -07:00
Randy Dunlap
19eea630f7 PCI: pci.c: fix kernel-doc notation
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>
2009-10-07 09:28:18 -07:00
Gabe Black
1f56f4a2b4 PCI quirk: TI XIO200a erroneously reports support for fast b2b transfers
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>
2009-10-07 09:28:17 -07:00
Rafael J. Wysocki
e13cdbd71f PCI PM: Read device power state from register after updating it
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>
2009-10-06 10:27:51 -07:00
Bjorn Helgaas
b812cca4e2 PCI: remove pci_assign_resource_fixed()
Adrian commented out this function in 2baad5f96b, 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>
2009-10-06 09:42:04 -07:00
Bjorn Helgaas
e3fb20f9c8 PCI: PCIe portdrv: remove "-driver" from driver name
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>
2009-10-06 09:41:48 -07:00
David Woodhouse
e0fc7e0b4b intel-iommu: Yet another BIOS workaround: Isoch DMAR unit with no TLB space
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>
2009-09-30 09:12:17 -07:00
Bjorn Helgaas
b24715027a ACPICA: fixup after acpi_get_object_info() change
Commit 15b8dd53f5 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>
2009-09-25 14:24:22 -04:00
Roland Dreier
17b6097753 intel-iommu: Decode (and ignore) RHSA entries
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>
2009-09-24 12:19:39 -07:00
Linus Torvalds
b7f21bb2e2 Merge branch 'linux-next' of 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
2009-09-24 09:57:08 -07:00
Roland Dreier
4de75cf939 intel-iommu: Make "Unknown DMAR structure" message more informative
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>
2009-09-23 17:31:27 -07:00
Linus Torvalds
b09a75fc5e Merge git://git.infradead.org/iommu-2.6
* 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
2009-09-23 10:06:10 -07:00
David Woodhouse
b94996c99c intel-iommu: Disable PMRs after we enable translation, not before
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2009-09-19 15:28:12 -07:00
Benjamin LaHaise
64de5af000 intel-iommu: Fix integer wrap on 32 bit kernels
The following 64 bit promotions are necessary to handle memory above the
4GiB boundary correctly.

[dwmw2: Fix the second part not to need 64-bit arithmetic at all]

Signed-off-by: Benjamin LaHaise <ben.lahaise@neterion.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2009-09-19 09:26:20 -07:00
David Woodhouse
59c36286b7 intel-iommu: Fix integer overflow in dma_pte_{clear_range,free_pagetable}()
If end_pfn is equal to (unsigned long)-1, then the loop will never end.

Seen on 32-bit kernel, but could have happened on 64-bit too once we get
hardware that supports 64-bit guest addresses.

Change both functions to a 'do {} while' loop with the test at the end,
and check for the PFN having wrapper round to zero.

Reported-by: Benjamin LaHaise <ben.lahaise@neterion.com>
Tested-by: Benjamin LaHaise <ben.lahaise@neterion.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2009-09-19 07:36:28 -07:00
David Woodhouse
2ebe31513f intel-iommu: Limit DOMAIN_MAX_PFN to fit in an 'unsigned long'
This means we're limited to 44-bit addresses on 32-bit kernels, and
makes it sane for us to use 'unsigned long' for PFNs throughout.

Which is just as well, really, since we already do that.

Reported-by: Benjamin LaHaise <ben.lahaise@neterion.com>
Tested-by: Benjamin LaHaise <ben.lahaise@neterion.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2009-09-19 07:34:04 -07:00
Len Brown
d26f0528d5 Merge branch 'misc-2.6.32' into release
Conflicts:
	drivers/pci/dmar.c

Signed-off-by: Len Brown <len.brown@intel.com>
2009-09-19 02:14:45 -04:00
Len Brown
985f38781d Merge branch 'acpica' into release 2009-09-19 01:45:22 -04:00
Len Brown
eb27cae8ad ACPI: linux/acpi.h should not include linux/dmi.h
users of acpi.h that need dmi.h should include it directly.

Signed-off-by: Len Brown <len.brown@intel.com>
2009-09-19 01:33:27 -04:00
Len Brown
003d6a38ce Merge branch 'sfi-base' into release
Conflicts:
	drivers/acpi/power.c

Signed-off-by: Len Brown <len.brown@intel.com>
2009-09-19 00:37:13 -04:00
Kenji Kaneshige
656927b119 PCI: pciehp: remove slot capabilities definitions
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>
2009-09-17 10:06:46 -07:00
Kenji Kaneshige
d9fb42a845 PCI: pciehp: remove error message definitions
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>
2009-09-17 10:06:41 -07:00
Kenji Kaneshige
07a09694de PCI: pciehp: remove number field
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>
2009-09-17 10:06:36 -07:00
Kenji Kaneshige
82a9e79ef1 PCI: pciehp: remove hpc_ops
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>
2009-09-17 10:06:31 -07:00
Kenji Kaneshige
385e24917e PCI: pciehp: remove pci_dev field
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>
2009-09-17 10:06:25 -07:00
Kenji Kaneshige
6aaa6d06f5 PCI: pciehp: remove crit_sect mutex
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>
2009-09-17 10:06:18 -07:00
Kenji Kaneshige
5f9cab7af6 PCI: pciehp: remove slot_bus field
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>
2009-09-17 10:06:14 -07:00
Kenji Kaneshige
d54798f034 PCI: pciehp: remove first_slot field
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>
2009-09-17 10:06:09 -07:00
Kenji Kaneshige
a2359a334f PCI: pciehp: remove slot_device_offset field
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>
2009-09-17 10:06:02 -07:00
Kenji Kaneshige
0e3631593c PCI: pciehp: remove hp_slot field
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>
2009-09-17 10:05:58 -07:00