- 01 11月, 2011 1 次提交
-
-
由 Paul Bolle 提交于
There's no other Kconfig symbol that depends on XEN_PCIDEV_FE_DEBUG. Neither is there anything that uses CONFIG_XEN_PCIDEV_FE_DEBUG. Signed-off-by: NPaul Bolle <pebolle@tiscali.nl> Reviewed-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: NMichal Marek <mmarek@suse.cz>
-
- 12 4月, 2011 1 次提交
-
-
由 Randy Dunlap 提交于
Create a kconfig option symbol for PCI_LABEL and enable it when DMI || ACPI are enabled. Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 05 3月, 2011 1 次提交
-
-
由 Narendra_K@Dell.com 提交于
This patch exports ACPI _DSM (Device Specific Method) provided firmware instance number and string name of PCI devices as defined by 'PCI Firmware Specification Revision 3.1' section 4.6.7.( DSM for Naming a PCI or PCI Express Device Under Operating Systems) to sysfs. New files created are: /sys/bus/pci/devices/.../label which contains the firmware name for the device in question, and /sys/bus/pci/devices/.../acpi_index which contains the firmware device type instance for the given device. cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/acpi_index 1 cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/label Embedded Broadcom 5709C NIC 1 cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/acpi_index 2 cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/label Embedded Broadcom 5709C NIC 2 The ACPI _DSM provided firmware 'instance number' and 'string name' will be given priority if the firmware also provides 'SMBIOS type 41 device type instance and string'. Signed-off-by: NMatthew Garrett <mjg@redhat.com> 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>
-
- 06 1月, 2011 1 次提交
-
-
由 Konrad Rzeszutek Wilk 提交于
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
- 18 10月, 2010 1 次提交
-
-
由 Ryan Wilson 提交于
This is a port of the 2.6.18 Xen PCI front driver with fixes to make it build under 2.6.34 and later (for the full list of changes: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git historic/xen-pcifront-0.1). It also includes the fixes to make it work properly. [v2: Updated Kconfig, removed crud, added Reviewed-by] [v3: Added 'static', fixed grant table leak, redid Kconfig] [v4: Added one more 'static' and removed comments] Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com> Reviewed-by: NJan Beulich <JBeulich@novell.com>
-
- 12 5月, 2010 1 次提交
-
-
由 Jesse Barnes 提交于
Most current machines have no problem with this, and in fact many devices and features work best (or only!) with MSI. Reported-by: NPetteri Räty <betelgeuse@gentoo.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 23 2月, 2010 1 次提交
-
-
由 Tilman Schmidt 提交于
The ISDN4Linux HiSax driver family contains the last remaining users of the deprecated pci_find_device() function. This patch creates a private copy of that function in HiSax, and removes the now unused global function together with its controlling configuration option, CONFIG_PCI_LEGACY. Signed-off-by: NTilman Schmidt <tilman@imap.cc> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 05 11月, 2009 2 次提交
-
-
Commit 3b073eda has removed pci_find_slot, so there's no point in mentioning it in the config description as one of the deprecated APIs there are enabled by PCI_LEGACY and still used by some drivers. Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@holoscopio.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Bjorn Helgaas 提交于
This patch moves PCI I/O APIC support from acpiphp to a separate driver. Like pciehp and shpchp, acpiphp handles PCI hotplug, i.e., addition and removal of PCI adapters. But in addition, acpiphp handles some ACPI hotplug, such as the addition of new host bridges, and the I/O APIC support was tangled up with that. I don't think the I/O APIC support needs to be in acpiphp; PCI I/O APICs usually appear as a function on a PCI host bridge, and we'll enumerate the APIC before any of the devices behind the bridge that use it. As far as I know, nobody actually uses I/O APIC hotplug. It depends on acpi_register_ioapic(), which is only implemented for ia64, and I don't think any vendors have supported I/O chassis hotplug yet. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> CC: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com> CC: MUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 21 3月, 2009 1 次提交
-
-
由 Yu Zhao 提交于
If a device has the SR-IOV capability, initialize it (set the ARI Capable Hierarchy in the lowest numbered PF if necessary; calculate the System Page Size for the VF MMIO, probe the VF Offset, Stride and BARs). A lock for the VF bus allocation is also initialized if a PF is the lowest numbered PF. Reviewed-by: NMatthew Wilcox <willy@linux.intel.com> Signed-off-by: NYu Zhao <yu.zhao@intel.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 08 1月, 2009 1 次提交
-
-
由 Chris Wright 提交于
When doing device assignment with KVM there's currently nothing to protect the device from having a driver in the host as well as the guest. This trivial module just binds the pci device on the host to a stub driver so that a real host driver can't bind to the device. It has no pci id table, it supports only dynamic ids. # echo "8086 10f5" > /sys/bus/pci/drivers/pci-stub/new_id # echo -n 0000:00:19.0 > /sys/bus/pci/drivers/e1000e/unbind # echo -n 0000:00:19.0 > /sys/bus/pci/drivers/pci-stub/bind # ls -l /sys/bus/pci/devices/0000:00:19.0/driver lrwxrwxrwx 1 root root 0 2008-11-25 19:10 /sys/bus/pci/devices/0000:00:19.0/driver -> ../../../bus/pci/drivers/pci-stub Cc: "Kay, Allen M" <allen.m.kay@intel.com> Cc: "Nakajima, Jun" <jun.nakajima@intel.com> Signed-off-by: NChris Wright <chrisw@sous-sol.org> Acked-by: NGreg Kroah-Hartman <gregkh@suse.de> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 06 11月, 2007 1 次提交
-
-
由 Jeff Garzik 提交于
Signed-off-by: NJeff Garzik <jgarzik@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 03 5月, 2007 2 次提交
-
-
由 Adrian Bunk 提交于
This patch removes the PCI_MULTITHREAD_PROBE option that had already been marked as broken. Signed-off-by: NAdrian Bunk <bunk@stusta.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Dan Williams 提交于
Allows architectures to advertise that they support MSI rather than listing each architecture as a PCI_MSI dependency. Signed-off-by: NDan Williams <dan.j.williams@intel.com> Acked-by: N"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 11 2月, 2007 1 次提交
-
-
由 David S. Miller 提交于
This is kind of hokey, we could use the hardware provided facilities much better. MSIs are assosciated with MSI Queues. MSI Queues generate interrupts when any MSI assosciated with it is signalled. This suggests a two-tiered IRQ dispatch scheme: MSI Queue interrupt --> queue interrupt handler MSI dispatch --> driver interrupt handler But we just get one-level under Linux currently. What I'd like to do is possibly stick the IRQ actions into a per-MSI-Queue data structure, and dispatch them form there, but the generic IRQ layer doesn't provide a way to do that right now. So, the current kludge is to "ACK" the interrupt by processing the MSI Queue data structures and ACK'ing them, then we run the actual handler like normal. We are wasting a lot of useful information, for example the MSI data and address are provided with ever MSI, as well as a system tick if available. If we could pass this into the IRQ handler it could help with certain things, in particular for PCI-Express error messages. The MSI entries on sparc64 also tell you exactly which bus/device/fn sent the MSI, which would be great for error handling when no registered IRQ handler can service the interrupt. We override the disable/enable IRQ chip methods in sun4v_msi, so we have to call {mask,unmask}_msi_irq() directly from there. This is another ugly wart. Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 06 1月, 2007 1 次提交
-
-
由 Andrew Morton 提交于
Unfortunatly, no one reads Kconfig help entries :( Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 02 12月, 2006 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
It's not really broken, but people keep running into other problems caused by it. Re-enable it so that the drivers get stress tested. Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 30 11月, 2006 2 次提交
-
-
由 Jan Engelhardt 提交于
Changes persistant -> persistent. www.dictionary.com does not know persistant (with an A), but should it be one of those things you can spell in more than one correct way, let me know. Signed-off-by: NJan Engelhardt <jengelh@gmx.de> Signed-off-by: NAdrian Bunk <bunk@stusta.de>
-
由 Matt LaPlante 提交于
Fix various Kconfig typos. Signed-off-by: NMatt LaPlante <kernel1@cyberdogtech.com> Acked-by: NRandy Dunlap <randy.dunlap@oracle.com> Signed-off-by: NAdrian Bunk <bunk@stusta.de>
-
- 04 11月, 2006 1 次提交
-
-
由 Adrian Bunk 提交于
PCI_MULTITHREAD_PROBE is an interesting feature, but in its current state it seems to be more of a trap for users who accidentally enable it. This patch lets PCI_MULTITHREAD_PROBE depend on BROKEN for 2.6.19. The intention is to get this patch reversed in -mm as soon as it's in Linus' tree, and reverse it for 2.6.20 or 2.6.21 after the fallout of in-kernel problems PCI_MULTITHREAD_PROBE causes got fixed. (akpm: I get enough bug reports already) Signed-off-by: NAdrian Bunk <bunk@stusta.de> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 12 10月, 2006 1 次提交
-
-
由 Adrian Bunk 提交于
CONFIG_PCI=n, CONFIG_HT_IRQ=y results in the following compile error: ... LD vmlinux arch/i386/mach-generic/built-in.o: In function `apicid_to_node': summit.c:(.text+0x53): undefined reference to `apicid_2_node' arch/i386/kernel/built-in.o: In function `arch_setup_ht_irq': (.text+0xcf79): undefined reference to `write_ht_irq_low' arch/i386/kernel/built-in.o: In function `arch_setup_ht_irq': (.text+0xcf85): undefined reference to `write_ht_irq_high' arch/i386/kernel/built-in.o: In function `k7nops': alternative.c:(.data+0x1358): undefined reference to `mask_ht_irq' alternative.c:(.data+0x1360): undefined reference to `unmask_ht_irq' make[1]: *** [vmlinux] Error 1 Bug report by Jesper Juhl. Signed-off-by: NAdrian Bunk <bunk@stusta.de> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 04 10月, 2006 2 次提交
-
-
由 Eric W. Biederman 提交于
This moves the declarations for the architecture helpers into include/linux/htirq.h from the generic include/linux/pci.h. Hopefully this will make this distinction clearer. htirq.h is included where it is needed. The dependency on the msi code is fixed and removed. The Makefile is tidied up. Signed-off-by: NEric W. Biederman <ebiederm@xmission.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Tony Luck <tony.luck@intel.com> Cc: Andi Kleen <ak@suse.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Greg KH <greg@kroah.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Eric W. Biederman 提交于
This patch implements two functions ht_create_irq and ht_destroy_irq for use by drivers. Several other functions are implemented as helpers for arch specific irq_chip handlers. The driver for the card I tested this on isn't yet ready to be merged. However this code is and hypertransport irqs are in use in a few other places in the kernel. Not that any of this will get merged before 2.6.19 Because the ipath-ht400 is slightly out of spec this code will need to be generalized to work there. I think all of the powerpc uses are for a plain interrupt controller in a chipset so support for native hypertransport devices is a little less interesting. However I think this is a half way decent model on how to separate arch specific and generic helper code, and I think this is a functional model of how to get the architecture dependencies out of the msi code. [akpm@osdl.org: Kconfig fix] Signed-off-by: NEric W. Biederman <ebiederm@xmission.com> Cc: Greg KH <greg@kroah.com> Cc: Andi Kleen <ak@muc.de> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 26 9月, 2006 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
This provides a build and run-time option to turn on multhreaded probe for all PCI drivers. It can cause bad problems on multi-processor machines that take a while to find their root disks, and play havoc on machines that don't use persistant device names for block or network devices. But it can cause speedups on some machines, my tiny laptop's boot goes up by 0.4 seconds, and my desktop boots up several seconds faster. Use at your own risk!!! Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 24 3月, 2006 2 次提交
-
-
由 Matthew Wilcox 提交于
Several drivers are starting to grow options to disable MSI. However, it's often a host chipset issue, not something which individual drivers should handle. So we add the pci=nomsi kernel parameter to allow the user to disable MSI modes for systems we haven't added to the quirk list yet. Signed-off-by: NMatthew Wilcox <matthew@wil.cx> Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net> Acked-by: NJeff Garzik <jeff@garzik.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Adrian Bunk 提交于
This patch contains the scheduled removal of PCI_LEGACY_PROC. Signed-off-by: NAdrian Bunk <bunk@stusta.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 09 9月, 2005 1 次提交
-
-
由 Adrian Bunk 提交于
This patch removes CONFIG_PCI_NAMES. Signed-off-by: NAdrian Bunk <bunk@stusta.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-