- 07 1月, 2012 1 次提交
-
-
由 Bjorn Helgaas 提交于
This doesn't change any functionality, but it makes a subsequent patch slightly simpler. pci_scan_bus(NULL, ...) and pci_scan_bus_parented() are identical except that pci_scan_bus() also calls pci_bus_add_devices(): pci_scan_bus_parented pci_create_bus pci_scan_child_bus pci_scan_bus pci_create_bus pci_scan_child_bus pci_bus_add_devices All callers of pcibios_scan_root() call pci_bus_add_devices() explicitly, and we don't pass a parent device, so we might as well use pci_scan_bus(). Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 15 10月, 2011 1 次提交
-
-
由 Jan Beulich 提交于
As with any other such change, the goal is to prevent inadvertent writes to these structures (assuming DEBUG_RODATA is enabled), and to separate data (possibly frequently) written to from such never getting modified. Reviewed-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NJan Beulich <jbeulich@novell.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 22 7月, 2011 1 次提交
-
-
由 Narendra_K@Dell.com 提交于
Commit 6e8af08d enables pci=bfsort on future Dell systems. But the identification string 'Dell System' matches on already existing whitelist, which do not have SMBIOS type 0xB1, causing pci=bfsort not being set on existing whitelist. This patch fixes the regression by moving the type 0xB1 check beyond the existing whitelist so that existing whitelist is walked before. Signed-off-by: NShyam Iyer <shyam_iyer@dell.com> Signed-off-by: NNarendra K <narendra_k@dell.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 15 1月, 2011 1 次提交
-
-
由 Narendra_K@Dell.com 提交于
This patch enables pci=bfsort by default on future Dell systems. It reads SMBIOS type 0xB1 vendor specific record and sets pci=bfsort accordingly. Offset Name Length Value Description 04 Flags0 Word Varies Bits 9-10 - 10:9 = 00 Unknown - 10:9 = 01 Breadth First - 10:9 = 10 Depth First - 10:9 = 11 Reserved 1. Any time pci=bfsort has to be enabled on a system, we need to add the model number of the system to the white list. With this patch, that is not required. 2. Typically, model number has to be added to the white list when the system is under development. With this change, that is not required. Signed-off-by: NJordan Hargrave <jordan_hargrave@dell.com> Signed-off-by: NNarendra K <narendra_k@dell.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 18 10月, 2010 1 次提交
-
-
由 Alex Nixon 提交于
Separate out x86 cache_line_size initialisation code into its own function (so it can be shared by Xen later in this patch series) [ Impact: cleanup ] Signed-off-by: NAlex Nixon <alex.nixon@citrix.com> Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: N"H. Peter Anvin" <hpa@zytor.com> Reviewed-by: NMatthew Wilcox <willy@linux.intel.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Cc: x86@kernel.org
-
- 31 7月, 2010 1 次提交
-
-
由 Mike Habeck 提交于
The Linux kernel assigns BARs that a BIOS did not assign, most likely to handle broken BIOSes that didn't enumerate the devices correctly. On UV the BIOS purposely doesn't assign I/O BARs for certain devices/ drivers we know don't use them (examples, LSI SAS, Qlogic FC, ...). We purposely don't assign these I/O BARs because I/O Space is a very limited resource. There is only 64k of I/O Space, and in a PCIe topology that space gets divided up into 4k chucks (this is due to the fact that a pci-to-pci bridge's I/O decoder is aligned at 4k)... Thus a system can have at most 16 cards with I/O BARs: (64k / 4k = 16) SGI needs to scale to >16 devices with I/O BARs. So by not assigning I/O BARs on devices we know don't use them, we can do that (iff the kernel doesn't go and assign these BARs that the BIOS purposely didn't assign). This patch will not assign a resource to a device BAR if that BAR was not assigned by the BIOS, and the kernel cmdline option 'pci=nobar' was specified. This patch is closely modeled after the 'pci=norom' option that currently exists in the tree. Signed-off-by: NMike Habeck <habeck@sgi.com> Signed-off-by: NMike Travis <travis@sgi.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 12 5月, 2010 1 次提交
-
-
由 Thomas Gleixner 提交于
pci_config_lock must be a real spinlock in preempt-rt. Convert it to raw_spinlock. No change for !RT kernels. Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 30 3月, 2010 1 次提交
-
-
由 Tejun Heo 提交于
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: NTejun Heo <tj@kernel.org> Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
-
- 24 2月, 2010 1 次提交
-
-
由 Bjorn Helgaas 提交于
The main benefit of using ACPI host bridge window information is that we can do better resource allocation in systems with multiple host bridges, e.g., http://bugzilla.kernel.org/show_bug.cgi?id=14183 Sometimes we need _CRS information even if we only have one host bridge, e.g., https://bugs.launchpad.net/ubuntu/+source/linux/+bug/341681 Most of these systems are relatively new, so this patch turns on "pci=use_crs" only on machines with a BIOS date of 2008 or newer. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 20 2月, 2010 1 次提交
-
-
由 Thomas Gleixner 提交于
The PCI initialization in pci_subsys_init() is a mess. pci_numaq_init, pci_acpi_init, pci_visws_init and pci_legacy_init are called and each implementation checks and eventually modifies the global variable pcibios_scanned. x86_init functions allow us to do this more elegant. The pci.init function pointer is preset to pci_legacy_init. numaq, acpi and visws can modify the pointer in their early setup functions. The functions return 0 when they did the full initialization including bus scan. A non zero return value indicates that pci_legacy_init needs to be called either because the selected function failed or wants the generic bus scan in pci_legacy_init to happen (e.g. visws). Signed-off-by: NThomas Gleixner <tglx@linutronix.de> LKML-Reference: <43F901BD926A4E43B106BF17856F07559FB80CFE@orsmsx508.amr.corp.intel.com> Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NJacob Pan <jacob.jun.pan@intel.com> Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
-
- 05 11月, 2009 2 次提交
-
-
由 Dave Jones 提交于
Instead of the PCI code needing to have code to determine the cacheline size of each processor, use the data the cpu identification code should have already determined during early boot. (The vendor checks are also incomplete, and don't take into account modern CPUs) I've been carrying a variant of this code in Fedora for a while, that prints debug information. There are a number of cases where we are currently setting the PCI cacheline size to 32 bytes, when the CPU cacheline size is 64 bytes. With this patch, we set them both the same. Signed-off-by: NDave Jones <davej@redhat.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Jesse Barnes 提交于
Till now, CLS has been determined either by arch code or as L1_CACHE_BYTES. Only x86 and ia64 set CLS explicitly and x86 doesn't always get it right. On most configurations, the chance is that firmware configures the correct value during boot. This patch makes pci_init() determine CLS by looking at what firmware has configured. It scans all devices and if all non-zero values agree, the value is used. If none is configured or there is a disagreement, pci_dfl_cache_line_size is used. arch can set the dfl value (via PCI_CACHE_LINE_BYTES or pci_dfl_cache_line_size) or override the actual one. ia64, x86 and sparc64 updated to set the default cls instead of the actual one. While at it, declare pci_cache_line_size and pci_dfl_cache_line_size in pci.h and drop private declarations from arch code. Signed-off-by: NTejun Heo <tj@kernel.org> Acked-by: NDavid Miller <davem@davemloft.net> Acked-by: NGreg KH <gregkh@suse.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tony Luck <tony.luck@intel.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 19 9月, 2009 1 次提交
-
-
由 Jesse Barnes 提交于
We use -1 to indicate no node affinity, so we need a signed type here or all sorts of bad things happen, like crashes in dev_attr_show as reported by Ingo: [ 158.058140] warning: `dbus-daemon' uses 32-bit capabilities (legacy support in use) [ 159.370562] BUG: unable to handle kernel NULL pointer dereference at (null) [ 159.372694] IP: [<ffffffff8143b722>] bitmap_scnprintf+0x72/0xd0 [ 159.372694] PGD 71d3e067 PUD 7052e067 PMD 0 [ 159.372694] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC [ 159.372694] last sysfs file: /sys/devices/pci0000:00/0000:00:01.0/local_cpus [ 159.372694] CPU 0 [ 159.372694] Pid: 7364, comm: irqbalance Not tainted 2.6.31-tip #8043 System Product Name [ 159.372694] RIP: 0010:[<ffffffff8143b722>] [<ffffffff8143b722>] bitmap_scnprintf+0x72/0xd0 [ 159.372694] RSP: 0018:ffff8800712a1e38 EFLAGS: 00010246 [ 159.372694] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 159.372694] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff880077dc5000 [ 159.372694] RBP: ffff8800712a1e68 R08: 0000000000000001 R09: 0000000000000001 [ 159.372694] R10: ffffffff8215c47c R11: 0000000000000000 R12: 0000000000000000 [ 159.372694] R13: 0000000000000000 R14: 0000000000000ffe R15: ffff880077dc5000 [ 159.372694] FS: 00007f5f578f76f0(0000) GS:ffff880007000000(0000) knlGS:0000000000000000 [ 159.372694] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 159.372694] CR2: 0000000000000000 CR3: 0000000071a77000 CR4: 00000000000006f0 [ 159.372694] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 159.372694] DR3: ffffffff835109dc DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 159.372694] Process irqbalance (pid: 7364, threadinfo ffff8800712a0000, task ffff880070773000) [ 159.372694] Stack: [ 159.372694] 2222222222222222 ffff880077dc5000 fffffffffffffffb ffff88007d366b40 [ 159.372694] <0> ffff8800712a1f48 ffff88007d3840a0 ffff8800712a1e88 ffffffff8146332b [ 159.372694] <0> fffffffffffffff4 ffffffff82450718 ffff8800712a1ea8 ffffffff815a9a1f [ 159.372694] Call Trace: [ 159.372694] [<ffffffff8146332b>] local_cpus_show+0x3b/0x60 [ 159.372694] [<ffffffff815a9a1f>] dev_attr_show+0x2f/0x60 [ 159.372694] [<ffffffff8118ee6f>] sysfs_read_file+0xbf/0x1d0 [ 159.372694] [<ffffffff8112afe9>] vfs_read+0xc9/0x180 [ 159.372694] [<ffffffff8112c365>] sys_read+0x55/0x90 [ 159.372694] [<ffffffff810114f2>] system_call_fastpath+0x16/0x1b [ 159.372694] Code: 41 b9 01 00 00 00 44 8d 46 03 49 63 fc 0f 49 d3 c1 f8 1f 4c 01 ff c1 e8 1a c1 fa 06 41 c1 e8 02 8d 0c 03 48 63 d2 83 e1 3f 29 c1 <49> 8b 44 d5 00 48 c7 c2 8c 37 16 82 48 d3 e8 89 f1 44 89 f6 49 [ 159.372694] RIP [<ffffffff8143b722>] bitmap_scnprintf+0x72/0xd0 [ 159.372694] RSP <ffff8800712a1e38> [ 159.372694] CR2: 0000000000000000 [ 159.600828] ---[ end trace 35550c356e84e60c ]--- Reported-by: NIngo Molnar <mingo@elte.hu> Tested-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 10 9月, 2009 1 次提交
-
-
由 Jesse Barnes 提交于
The current mp_bus_to_node array is initialized only by AMD specific code, since AMD platforms have registers that can be used for determining mode numbers. On new Intel platforms it's necessary to initialize this array as well though, otherwise all PCI node numbers will be 0, when in fact they should be -1 (indicating that I/O isn't tied to any particular node). So move the mp_bus_to_node code into the common PCI code, and initialize it early with a default value of -1. This may be overridden later by arch code (e.g. the AMD code). With this change, PCI consistent memory and other node specific allocations (e.g. skbuff allocs) should occur on the "current" node. If, for performance reasons, applications want to be bound to specific nodes, they should open their devices only after being pinned to the CPU where they'll run, for maximum locality. Acked-by: NYinghai Lu <yinghai@kernel.org> Tested-by: NJesse Brandeburg <jesse.brandeburg@gmail.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 25 6月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
This reverts commit 9e9f46c4. Quoting from the commit message: "At this point, it seems to solve more problems than it causes, so let's try using it by default. It's an easy revert if it ends up causing trouble." And guess what? The _CRS code causes trouble. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 12 6月, 2009 1 次提交
-
-
由 Jesse Barnes 提交于
At this point, it seems to solve more problems than it causes, so let's try using it by default. It's an easy revert if it ends up causing trouble. Reviewed-by: NYinghai Lu <yhlu.kernel@gmail.com> Acked-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 23 4月, 2009 2 次提交
-
-
由 Yinghai Lu 提交于
Rename set_pci_bus_resources_arch_default to x86_pci_root_bus_res_quirks, move the weak version from common.c to i386.c, and before calling, make sure it's a root bus. Reviewed-by: NMatthew Wilcox <willy@linux.intel.com> Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Matthew Wilcox 提交于
Commit 30a18d6c introduced a new function to set the PCI bus resources. Unfortunately, neither the author, nor the committers seemed to know that we already have somewhere to do that -- pcibios_fixup_bus(). This patch moves the hook (used only by the K8 code) into x86-specific code where it should have been in the first place. Cc: Yinghai Lu <yinghai.lu@sun.com> Signed-off-by: NMatthew Wilcox <willy@linux.intel.com> Acked-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 12 3月, 2009 1 次提交
-
-
由 Jan Beulich 提交于
Impact: debuggability and micro-optimization Putting whatever is possible into the (final) .rodata section increases the likelihood of catching memory corruption bugs early, and reduces false cache line sharing. Signed-off-by: NJan Beulich <jbeulich@novell.com> LKML-Reference: <49B909A5.76E4.0078.0@novell.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 08 1月, 2009 2 次提交
-
-
由 Rafael J. Wysocki 提交于
pcibios_enable_device() and pcibios_disable_device() don't handle IRQs for devices that have MSI enabled and it should treat the devices with MSI-X enabled in the same way. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Acked-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Andrew Patterson 提交于
The _OSC capability OSC_EXT_PCI_CONFIG_SUPPORT is set when the root bridge is added with pci_acpi_osc_support() if we can access PCI extended config space. This adds the function pci_ext_cfg_avail which returns true if we can access PCI extended config space (offset greater than 0xff). It currently only returns false if arch=x86 and raw_pci_ext_ops is not set (which might happen if pci=nommcfg is set on the kernel command-line). Signed-off-by: NAndrew Patterson <andrew.patterson@hp.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 30 12月, 2008 1 次提交
-
-
由 Jaswinder Singh Rajput 提交于
Impact: cleanup Now that arch/x86/pci/pci.h is used in a number of other places as well, move the lowlevel x86 pci definitions into the architecture include files. (not to be confused with the existing arch/x86/include/asm/pci.h file, which provides public details about x86 PCI) Tested on: X86_32_UP, X86_32_SMP and X86_64_SMP Signed-off-by: NJaswinder Singh Rajput <jaswinderrajput@gmail.com> Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 19 7月, 2008 1 次提交
-
-
由 Stefan Assmann 提交于
x86, pci: introduce config option for pci reroute quirks (was: [PATCH 0/3] Boot IRQ quirks for Broadcom and AMD/ATI) This is against linux-2.6-tip, branch pci-ioapic-boot-irq-quirks. From: Stefan Assmann <sassmann@suse.de> Subject: Introduce config option for pci reroute quirks The config option X86_REROUTE_FOR_BROKEN_BOOT_IRQS is introduced to enable (or disable) the redirection of the interrupt handler to the boot interrupt line by default. Depending on the existence of interrupt masking / threaded interrupt handling in the kernel (vanilla, rt, ...) and the maturity of the rerouting patch, users can enable or disable the redirection by default. This means that the reroute quirk can be applied to any kernel without changing it. Interrupt sharing could be increased if this option is enabled. However this option is vital for threaded interrupt handling, as done by the RT kernel. It should simplify the consolidation with the RT kernel. The option can be overridden by either pci=ioapicreroute or pci=noioapicreroute. Signed-off-by: NStefan Assmann <sassmann@suse.de> Signed-off-by: NOlaf Dabrunz <od@suse.de> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Jon Masters <jonathan@jonmasters.org> Cc: Ihno Krumreich <ihno@suse.de> Cc: Sven Dietrich <sdietrich@suse.de> Cc: Daniel Gollub <dgollub@suse.de> Cc: Felix Foerster <ffoerster@suse.de> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 15 7月, 2008 1 次提交
-
-
由 Matthew Wilcox 提交于
John Keller reports that PCI config space access is broken on machines with more than one domain. conf1 accesses only work for domain 0, so make sure we check the domain number in the raw routines before trying conf1. Reported-by: NJohn Keller <jpk@sgi.com> Signed-off-by: NMatthew Wilcox <willy@linux.intel.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 09 7月, 2008 1 次提交
-
-
由 Robert Richter 提交于
So far subsys_initcalls has been executed in this order depending on the object order in the Makefile: arch/x86/pci/visws.c:subsys_initcall(pcibios_init); arch/x86/pci/numa.c:subsys_initcall(pci_numa_init); arch/x86/pci/acpi.c:subsys_initcall(pci_acpi_init); arch/x86/pci/legacy.c:subsys_initcall(pci_legacy_init); arch/x86/pci/irq.c:subsys_initcall(pcibios_irq_init); arch/x86/pci/common.c:subsys_initcall(pcibios_init); This patch removes the ordering dependency. There is now only one subsys_initcall function that contains subsystem initialization code with a defined order. Signed-off-by: NRobert Richter <robert.richter@amd.com> Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 08 7月, 2008 3 次提交
-
-
由 Stefan Assmann 提交于
Introduce pci=ioapicreroute kernel cmdline option to enable rerouting of boot interrupts to the primary io-apic. Signed-off-by: NStefan Assmann <sassmann@suse.de> Signed-off-by: NOlaf Dabrunz <od@suse.de> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Stefan Assmann 提交于
Introduce pci=noioapicquirk kernel cmdline option to disable all boot interrupt quirks Signed-off-by: NStefan Assmann <sassmann@suse.de> Signed-off-by: NOlaf Dabrunz <od@suse.de> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Jesse Barnes 提交于
This reverts commit a1676072. It duplicates the change from 8d64c781 and only one should be applied, otherwise some of the Dell quirks are lost. Thanks to Tony Camuso for catching this. Acked-by: NTony Camuso <tcamuso@redhat.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 11 6月, 2008 2 次提交
-
-
由 Yinghai Lu 提交于
Allows us to dump PCI space before any kernel changes have been made. Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Gary Hade 提交于
Contention for scarce PCI memory resources has been growing due to an increasing number of PCI slots in large multi-node systems. The kernel currently attempts by default to allocate memory for all PCI expansion ROMs so there has also been an increasing number of PCI memory allocation failures seen on these systems. This occurs because the BIOS either (1) provides insufficient PCI memory resource for all the expansion ROMs or (2) provides adequate PCI memory resource for expansion ROMs but provides the space in kernel unexpected BIOS assigned P2P non-prefetch windows. The resulting PCI memory allocation failures may be benign when related to memory requests for expansion ROMs themselves but in some cases they can occur when attempting to allocate space for more critical BARs. This can happen when a successful expansion ROM allocation request consumes memory resource that was intended for a non-ROM BAR. We have seen this happen during PCI hotplug of an adapter that contains a P2P bridge where successful memory allocation for an expansion ROM BAR on device behind the bridge consumed memory that was intended for a non-ROM BAR on the P2P bridge. In all cases the allocation failure messages can be very confusing for users. This patch provides a new 'pci=norom' kernel boot parameter that can be used to disable the default PCI expansion ROM memory resource allocation. This provides a way to avoid the above described issues on systems that do not contain PCI devices for which drivers or user-level applications depend on the default PCI expansion ROM memory resource allocation behavior. Signed-off-by: NGary Hade <garyhade@us.ibm.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 23 5月, 2008 1 次提交
-
-
由 Tony Camuso 提交于
Greetings. There is a code flaw in the bfsort whitelist, where there are redundant entries for the same two HP systems, DL385 G2 and DL585 G2. This patch replaces those redundant entries with the correct ones. The correct entries are for large-volume systems, the DL360 and DL380. ----------------------------------------------------------------------- commit ec69f0374c3b0ad7ea991b0e9ac00377acfe5b1a Author: Tony Camuso <tony.camuso@hp.com> Date: Wed May 14 07:09:28 2008 -0400 Replace Redundant Whitelist Entries with the Correct Ones The ProLiant DL585 G2 and the DL585 G2 are entered reundantly in the dmi_system_id table. What should have been there are the DL360 and DL380. This patch simply replaces the redundant entries with the correct entries. arch/x86/pci/common.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) Signed-off-by: NTony Camuso <tony.camuso@hp.com> Signed-off-by: NPat Schoeller <patrick.schoeller@hp.com> Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
- 20 5月, 2008 1 次提交
-
-
由 Tony Camuso 提交于
Replace Redundant Whitelist Entries with the Correct Ones The ProLiant DL585 G2 and the DL585 G2 are entered reundantly in the dmi_system_id table. What should have been there are the DL360 and DL380. This patch simply replaces the redundant entries with the correct entries. Signed-off-by: NTony Camuso <tony.camuso@hp.com> Signed-off-by: NPat Schoeller <patrick.schoeller@hp.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 09 5月, 2008 1 次提交
-
-
由 Linus Torvalds 提交于
This reverts commit 9f8dacca, which was reported to break X startup (xf86-video-ati-6.8.0). See http://bugs.freedesktop.org/show_bug.cgi?id=15523 for details. Reported-by: NLaurence Withers <l@lwithers.me.uk> Cc: Gary Hade <garyhade@us.ibm.com> Cc: Greg KH <greg@kroah.com> Cc: Jan Beulich <jbeulich@novell.com> Cc: "Jun'ichi Nomura" <j-nomura@ce.jp.nec.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 06 5月, 2008 2 次提交
-
-
由 Yinghai Lu 提交于
this change: | commit 08f1c192 | Author: Muli Ben-Yehuda <muli@il.ibm.com> | Date: Sun Jul 22 00:23:39 2007 +0300 | | x86-64: introduce struct pci_sysdata to facilitate sharing of ->sysdata | | This patch introduces struct pci_sysdata to x86 and x86-64, and | converts the existing two users (NUMA, Calgary) to use it. | | This lays the groundwork for having other users of sysdata, such as | the PCI domains work. | | The Calgary bits are tested, the NUMA bits just look ok. replaces pcibios_scan_root with pci_scan_bus_parented... but in pcibios_scan_root we have a DMI check: dmi_check_system(pciprobe_dmi_table); when when have several peer root buses this could be called multiple times (which is bad), so move that call to pci_access_init(). Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Yinghai Lu 提交于
so we don't align the io port start address for pci cards. also move out dmi check out acpi.c, because it has nothing to do with acpi. it could spare some calling when we have several peer root buses. Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 30 4月, 2008 1 次提交
-
-
由 Sam Ravnborg 提交于
Fix following section mismatch warning: WARNING: vmlinux.o(.text+0x275616): Section mismatch in reference from the function pci_scan_bus() to the function .devinit.text:pci_scan_bus_parented() The warning was seen with a CONFIG_DEBUG_SECTION_MISMATCH=y build. The inline function pci_scan_bus refer to functions annotated __devinit - so annotate it __devinit too. This revealed a few x86 specific functions that were only used from __init or __devinit context. So annotate these __devinit and the warning was killed. The added include in pci.h was not strictly required but added to avoid being dependent on indirect includes. Signed-off-by: NSam Ravnborg <sam@ravnborg.org> Signed-off-by: NJesse Barnes <jbarnes@hobbes.lan>
-
- 27 4月, 2008 2 次提交
-
-
由 Yinghai Lu 提交于
so will disable that feature by default, and only enable that via pci=check_enable_amd_mmconf or for system match with dmi table. Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 Yinghai Lu 提交于
Currently, on an amd k8 system with multi ht chains, the numa_node of pci devices under /sys/devices/pci0000:80/* is always 0, even if that chain is on node 1 or 2 or 3. Workaround: pcibus_to_node(bus) is used when we want to get the node that pci_device is on. In struct device, we already have numa_node member, and we could use dev_to_node()/set_dev_node() to get and set numa_node in the device. set_dev_node is called in pci_device_add() with pcibus_to_node(bus), and pcibus_to_node uses bus->sysdata for nodeid. The problem is when pci_add_device is called, bus->sysdata is not assigned correct nodeid yet. The result is that numa_node will always be 0. pcibios_scan_root and pci_scan_root could take sysdata. So we need to get mp_bus_to_node mapping before these two are called, and thus get_mp_bus_to_node could get correct node for sysdata in root bus. In scanning of the root bus, all child busses will take parent bus sysdata. So all pci_device->dev.numa_node will be assigned correctly and automatically. Later we could use dev_to_node(&pci_dev->dev) to get numa_node, and we could also could make other bus specific device get the correct numa_node too. This is an updated version of pci_sysdata and Jeff's pci_domain patch. [ mingo@elte.hu: build fix ] Signed-off-by: NYinghai Lu <yinghai.lu@sun.com> Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
- 21 4月, 2008 2 次提交
-
-
由 Bjorn Helgaas 提交于
Use the generic pci_enable_resources() instead of the arch-specific code. Unlike this arch-specific code, the generic version: - checks for resource collisions with "!r->parent" Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Greg Kroah-Hartman 提交于
This function was obviously never being used since early 2.5 days as any device that it would try to remove would never really be removed from the system due to the PCI device list being held in the driver core, not the general list of PCI devices. As we have not had a single report of a problem here in 4 years, I think it's safe to remove now. Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-