summaryrefslogtreecommitdiffstats
path: root/drivers/pci (follow)
Commit message (Collapse)AuthorAgeFilesLines
* 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-241-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-201-2/+3
| | | | | | | | | | | | Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * | intel-iommu: Fix integer wrap on 32 bit kernelsBenjamin LaHaise2009-09-191-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | intel-iommu: Fix integer overflow in dma_pte_{clear_range,free_pagetable}()David Woodhouse2009-09-191-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | intel-iommu: Limit DOMAIN_MAX_PFN to fit in an 'unsigned long'David Woodhouse2009-09-191-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | intel-iommu: Fix kernel hang if interrupt remapping disabled in BIOSYouquan Song2009-09-112-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BIOS clear DMAR table INTR_REMAP flag to disable interrupt remapping. Current kernel only check interrupt remapping(IR) flag in DRHD's extended capability register to decide interrupt remapping support or not. But IR flag will not change when BIOS disable/enable interrupt remapping. When user disable interrupt remapping in BIOS or BIOS often defaultly disable interrupt remapping feature when BIOS is not mature.Though BIOS disable interrupt remapping but intr_remapping_supported function will always report to OS support interrupt remapping if VT-d2 chipset populated. On this cases, kernel will continue enable interrupt remapping and result kernel panic. This bug exist on almost all platforms with interrupt remapping support. This patch add DMAR table INTR_REMAP flag check before enable interrupt remapping. Signed-off-by: Youquan Song <youquan.song@intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * | intel-iommu: Disallow interrupt remapping if not all ioapics coveredYouquan Song2009-09-112-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current kernel enable interrupt remapping only when all the vt-d unit support interrupt remapping. So it is reasonable we should also disallow enabling intr-remapping if there any io-apics that are not listed under vt-d units. Otherwise we can run into issues. Acked-by: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Youquan Song <youquan.song@intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * | intel-iommu: include linux/dmi.h to use dmi_ routinesStephen Rothwell2009-08-311-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | This file needs to include linux/dmi.h directly rather than relying on it being pulled in from elsewhere. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * | pci/dmar: correct off-by-one error in dmar_fault()Troy Heber2009-08-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DMAR faults are recorded into a ring of "fault recording registers". fault_index is a 0-based index into the ring. The code allows the 0-based fault_index to be equal to the total number of fault registers available from the cap_num_fault_regs() macro, which causes access beyond the last available register. Signed-off-by Troy Heber <troy.heber@hp.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * | intel-iommu: Cope with yet another BIOS screwup causing crashesDavid Woodhouse2009-08-261-0/+11
| | | | | | | | | | | | Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * | intel-iommu: iommu init error path bug fixesDonald Dutile2009-08-241-17/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The kcalloc() failure path in iommu_init_domains() calls free_dmar_iommu(), which assumes that ->domains, ->domain_ids, and ->lock have been properly initialized. Add checks in free_[dmar]_iommu to not use ->domains,->domain_ids if not alloced. Move the lock init to prior to the kcalloc()'s, so it is valid in free_context_table() when free_dmar_iommu() invokes it at the end. Patch based on iommu-2.6, commit 132032274a594ee9ffb6b9c9e2e9698149a09ea9 Signed-off-by: Donald Dutile <ddutile@redhat.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-29 03:06:02 +0100