linux-toradex.git/drivers/pci, branch tegra-10.9.9

PCI: AER: fix aer inject result in kernel oops

2010-01-28T23:01:51+00:00

commit 46256f83d0d066f99ffde547f27473dfd2a78009 upstream.

If the BIOS does not export _OSC to allow OS take over the PCIe AER, the
pcie aer driver will not initialize the aer service. However, the
aer_inject driver does not check this scenario, which results in a kernel
oops when injecting an aer error into OS.  For example:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000350
IP: [] _spin_lock_irqsave+0xc/0x23
PGD 155c41067 PUD 157fe0067 PMD 0
Oops: 0002 [#1] SMP
Pid: 5119, comm: aer-inject Not tainted 2.6.32-rc8-mce #2
RIP: 0010:[]  [] _spin_lock_irqsave+0xc/0x23
RSP: 0018:ffff880157f81e28  EFLAGS: 00010096
RAX: 0000000000000296 RBX: 0000000000000000 RCX: 0000000000000100
RDX: 0000000000010000 RSI: 0000000000000246 RDI: 0000000000000350
RBP: ffff880157f81e28 R08: 0000000000000004 R09: ffff880157f81dac
R10: ffff88015a666f60 R11: ffff88015a666f40 R12: ffff88015758cc00
R13: 0000000000000350 R14: 0000000000000000 R15: 0000000000000100
FS:  00007f4d4a66e6f0(0000) GS:ffff8800282e0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000350 CR3: 000000015661a000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process aer-inject (pid: 5119, threadinfo ffff880157f80000, task ffff8801585f4340)
Stack:
 ffff880157f81e78 ffffffff811b1615 ffff880157f81e78 ffffffff81222823
Call Trace:
 [] aer_irq+0x38/0x117
 [] ? device_for_each_child+0x5f/0x6f
 [] aer_inject_write+0x409/0x45e [aer_inject]
 [] vfs_write+0xae/0x16a
 [] sys_write+0x47/0x6e
 [] system_call_fastpath+0x16/0x1b
RIP  [] _spin_lock_irqsave+0xc/0x23
 RSP 
CR2: 0000000000000350

So check the _OSC before assuming that AER is available to the OS.

Signed-off-by: Song Youquan 
Acked-by: Huang Ying 
Signed-off-by: Jesse Barnes 
Signed-off-by: Thomas Renninger 
Signed-off-by: Greg Kroah-Hartman

PCI: Always set prefetchable base/limit upper32 registers

2010-01-28T23:01:15+00:00

commit 59353ea30e65ab3ae181d6175e3212e1361c3787 upstream.

Prior to 1f82de10 we always initialized the upper 32bits of the
prefetchable memory window, regardless of the address range used.
Now we only touch it for a >32bit address, which means the upper32
registers remain whatever the BIOS initialized them too.

It's valid for the BIOS to set the upper32 base/limit to
0xffffffff/0x00000000, which makes us program prefetchable ranges
like 0xffffffffabc00000 - 0x00000000abc00000

Revert the chunk of 1f82de10 that made this conditional so we always
write the upper32 registers and remove now unused pref_mem64 variable.

Signed-off-by: Alex Williamson 
Signed-off-by: Jesse Barnes 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

PCI/cardbus: Add a fixup hook and fix powerpc

2010-01-22T23:18:26+00:00

commit 2d1c861871d767153538a77c498752b36d4bb4b8 upstream

The cardbus code creates PCI devices without ever going through the
necessary fixup bits and pieces that normal PCI devices go through.

There's in fact a commented out call to pcibios_fixup_bus() in there,
it's commented because ... it doesn't work.

I could make pcibios_fixup_bus() do the right thing on powerpc easily
but I felt it cleaner instead to provide a specific hook pci_fixup_cardbus
for which a weak empty implementation is provided by the PCI core.

This fixes cardbus on powerbooks and probably all other PowerPC
platforms which was broken completely for ever on some platforms and
since 2.6.31 on others such as PowerBooks when we made the DMA ops
mandatory (since those are setup by the fixups).

Acked-by: Dominik Brodowski 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Jesse Barnes 
Signed-off-by: Stefan Bader 
Acked-by: Benjamin Herrenschmidt 
Acked-by: Jesse Barnes 
Signed-off-by: Greg Kroah-Hartman

intel-iommu: ignore page table validation in pass through mode

2009-12-18T22:05:59+00:00

commit 1672af1164d3d50ba8908014fd34cc0b58afdc1e upstream.

We are seeing a bug when booting w/ iommu=pt with current upstream
(bisect blames 19943b0e30b05d42e494ae6fef78156ebc8c637e "intel-iommu:
Unify hardware and software passthrough support).

The issue is specific to this loop during identity map initialization
of each device:

domain_context_mapping_one(si_domain, ..., CONTEXT_TT_PASS_THROUGH)
...
		/* Skip top levels of page tables for
		* iommu which has less agaw than default.
		*/
		for (agaw = domain->agaw; agaw != iommu->agaw; agaw--) {
			pgd = phys_to_virt(dma_pte_addr(pgd));
			if (!dma_pte_present(pgd)) {      <------ failing here
				spin_unlock_irqrestore(&iommu->lock, flags);
			return -ENOMEM;
		}

This box has 2 iommu's in it.  The catchall iommu has MGAW == 48, and
SAGAW == 4.  The other iommu has MGAW == 39, SAGAW == 2.

The device that's failing the above pgd test is the only device connected
to the non-catchall iommu, which has a smaller address width than the
domain default.  This test is not necessary since the context is in PT
mode and the ASR is ignored.

Thanks to Don Dutile for discovering and debugging this one.

Signed-off-by: Chris Wright 
Signed-off-by: David Woodhouse 
Signed-off-by: Greg Kroah-Hartman

intel-iommu: Fix oops with intel_iommu=igfx_off

2009-12-18T22:05:57+00:00

commit 44cd613c0e4cd93079ea2a93aa06649d8ca0830a upstream.

The hotplug notifier will call find_domain() to see if the device in
question has been assigned an IOMMU domain. However, this should never
be called for devices with a "dummy" domain, such as graphics devices
when intel_iommu=igfx_off is set and the corresponding IOMMU isn't even
initialised. If you do that, it'll oops as it dereferences the (-1)
pointer.

The notifier function should check iommu_no_mapping() for the
device before doing anything else.

Signed-off-by: David Woodhouse 
Signed-off-by: Greg Kroah-Hartman

intel-iommu: Check for an RMRR which ends before it starts.

2009-12-18T22:05:55+00:00

commit 5595b528b49a702c0428c0762bab60999648254c upstream.

Some HP BIOSes report an RMRR region (a region which needs a 1:1 mapping
in the IOMMU for a given device) which has an end address lower than its
start address. Detect that and warn, rather than triggering the
BUG() in dma_pte_clear_range().

Signed-off-by: David Woodhouse 
Signed-off-by: Greg Kroah-Hartman

intel-iommu: Apply BIOS sanity checks for interrupt remapping too.

2009-12-18T22:05:54+00:00

commit 6ecbf01c7ce4c0f4c3bdfa0e64ac6258328fda6c upstream.

The BIOS errors where an IOMMU is reported either at zero or a bogus
address are causing problems even when the IOMMU is disabled -- because
interrupt remapping uses the same hardware. Ensure that the checks get
applied for the interrupt remapping initialisation too.

Signed-off-by: David Woodhouse 
Signed-off-by: Greg Kroah-Hartman

intel-iommu: Detect DMAR in hyperspace at probe time.

2009-12-18T22:05:53+00:00

commit 2c99220810c1c79322034628b993573b088ff2da upstream.

Many BIOSes will lie to us about the existence of an IOMMU, and claim
that there is one at an address which actually returns all 0xFF.

We need to detect this early, so that we know we don't have a viable
IOMMU and can set up swiotlb before it's too late.

Signed-off-by: Chris Wright 
Signed-off-by: David Woodhouse 
Signed-off-by: Greg Kroah-Hartman

Fix handling of the HP/Acer 'DMAR at zero' BIOS error for machines with <4GiB RAM.

2009-11-19T21:42:02+00:00

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 
Signed-off-by: Linus Torvalds

Merge git://git.infradead.org/users/dwmw2/iommu-2.6.32

2009-11-14T21:05:27+00:00

* 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.