- 17 2月, 2016 1 次提交
-
-
由 Jake Oshins 提交于
Add a new driver which exposes a root PCI bus whenever a PCI Express device is passed through to a guest VM under Hyper-V. The device can be single- or multi-function. The interrupts for the devices are managed by an IRQ domain, implemented within the driver. [bhelgaas: fold in race condition fix (http://lkml.kernel.org/r/1456340196-13717-1-git-send-email-jakeo@microsoft.com)] Signed-off-by: NJake Oshins <jakeo@microsoft.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 08 9月, 2015 1 次提交
-
-
由 Helge Deller 提交于
Commit 3a9ad0b4 ("PCI: Add pci_bus_addr_t") unconditionally introduced usage of 64-bit PCI bus addresses on all 64-bit platforms which broke PA-RISC. It turned out that due to enabling the 64-bit addresses, the PCI logic decided to use the GMMIO instead of the LMMIO region. This commit simply disables registering the GMMIO and thus we fall back to use the LMMIO region as before. Reverts commit 45ea2a5f ("PCI: Don't use 64-bit bus addresses on PA-RISC") To: linux-parisc@vger.kernel.org Cc: linux-pci@vger.kernel.org Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Meelis Roos <mroos@linux.ee> Cc: stable@vger.kernel.org # v3.19+ Signed-off-by: NHelge Deller <deller@gmx.de>
-
- 21 8月, 2015 1 次提交
-
-
由 Bjorn Helgaas 提交于
Meelis and Helge reported that 3a9ad0b4 ("PCI: Add pci_bus_addr_t") caused HPMCs on A500 and hangs on rp5470. PA-RISC does not set ARCH_DMA_ADDR_T_64BIT, even for 64-bit kernels, so prior to 3a9ad0b4, we always used 32-bit PCI addresses. After 3a9ad0b4, we do use 64-bit PCI addresses in 64-bit kernels, and apparently there's some PA-RISC problem related to them. Fixes: 3a9ad0b4 ("PCI: Add pci_bus_addr_t") Link: http://lkml.kernel.org/r/alpine.LRH.2.11.1507260929000.30065@math.ut.eeReported-by: NMeelis Roos <mroos@linux.ee> Reported-by: NHelge Deller <deller@gmx.de> Tested-by: NHelge Deller <deller@gmx.de> Based-on-idea-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NYinghai Lu <yinghai@kernel.org> CC: stable@vger.kernel.org # v3.19+
-
- 30 5月, 2015 1 次提交
-
-
由 Yinghai Lu 提交于
David Ahern reported that d63e2e1f ("sparc/PCI: Clip bridge windows to fit in upstream windows") fails to boot on sparc/T5-8: pci 0000:06:00.0: reg 0x184: can't handle BAR above 4GB (bus address 0x110204000) The problem is that sparc64 assumed that dma_addr_t only needed to hold DMA addresses, i.e., bus addresses returned via the DMA API (dma_map_single(), etc.), while the PCI core assumed dma_addr_t could hold *any* bus address, including raw BAR values. On sparc64, all DMA addresses fit in 32 bits, so dma_addr_t is a 32-bit type. However, BAR values can be 64 bits wide, so they don't fit in a dma_addr_t. d63e2e1f added new checking that tripped over this mismatch. Add pci_bus_addr_t, which is wide enough to hold any PCI bus address, including both raw BAR values and DMA addresses. This will be 64 bits on 64-bit platforms and on platforms with a 64-bit dma_addr_t. Then dma_addr_t only needs to be wide enough to hold addresses from the DMA API. [bhelgaas: changelog, bugzilla, Kconfig to ensure pci_bus_addr_t is at least as wide as dma_addr_t, documentation] Fixes: d63e2e1f ("sparc/PCI: Clip bridge windows to fit in upstream windows") Fixes: 23b13bc7 ("PCI: Fail safely if we can't handle BARs larger than 4GB") Link: http://lkml.kernel.org/r/CAE9FiQU1gJY1LYrxs+ma5LCTEEe4xmtjRG0aXJ9K_Tsu+m9Wuw@mail.gmail.com Link: http://lkml.kernel.org/r/1427857069-6789-1-git-send-email-yinghai@kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=96231Reported-by: NDavid Ahern <david.ahern@oracle.com> Tested-by: NDavid Ahern <david.ahern@oracle.com> Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NDavid S. Miller <davem@davemloft.net> CC: stable@vger.kernel.org # v3.19+
-
- 16 12月, 2014 2 次提交
-
-
由 Jiang Liu 提交于
Now we have splitted functions to support MSI and HT_IRQ into vector.c, and they have no dependency on IOAPIC any more. So change Kconfig files to make MSI and HT_IRQ independent of X86_IO_APIC. Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Tony Luck <tony.luck@intel.com> Cc: Joerg Roedel <joro@8bytes.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Link: http://lkml.kernel.org/r/1414397531-28254-16-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 Jiang Liu 提交于
To support IOAPIC hotplug on x86 and IA64 platforms, OS needs to figure out global interrupt source number(GSI) and IOAPIC enumeration ID through ACPI interfaces. So BIOS must implement an ACPI IOAPIC device with _GSB/_UID or _MAT method to support IOAPIC hotplug. OS also needs to figure out base physical address to access IOAPIC registers. OS may get the base physical address through PCI BARs if IOAPIC device is visible in PCI domain, otherwise OS may get the address by ACPI _CRS method if IOAPIC device is hidden from PCI domain by BIOS. When adding a PCI subtree, we need to add IOAPIC devices before enabling all other PCI devices because other PCI devices may use the IOAPIC to allocate PCI interrupts. So we plan to reimplement IOAPIC driver as an ACPI instead of PCI driver due to: 1) hot-pluggable IOAPIC devices are always visible in ACPI domain, but may or may not be visible in PCI domain. 2) we could explicitly control the order between IOAPIC and other PCI devices. We also have another choice to use a PCI driver to manage IOAPIC device if it's visible in PCI domain and use an ACPI driver if it's only visible in ACPI domain. But this solution is a little complex. It shouldn't cause serious backward compatibility issues because: 1) IOAPIC hotplug is never supported on x86 yet because it hasn't implemented the required acpi_register_ioapic() and acpi_unregister_ioapic(). 2) Currently only ACPI based IOAPIC hotplug is possible on x86 and IA64, we don't know other specifications and interfaces to support IOAPIC hotplug yet. 3) We will reimplement an ACPI IOAPIC driver to support IOAPIC hotplug. This change also helps to get rid of the false alarm on all current Linux distributions: [ 6.952497] ioapic: probe of 0000:00:05.4 failed with error -22 [ 6.959542] ioapic: probe of 0000:80:05.4 failed with error -22 Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Tony Luck <tony.luck@intel.com> Cc: Joerg Roedel <joro@8bytes.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Link: http://lkml.kernel.org/r/1414387308-27148-9-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
-
- 23 11月, 2014 2 次提交
-
-
由 Jiang Liu 提交于
Enhance PCI MSI core to support hierarchy irqdomain, so the common code can be shared across architectures. [ tglx: Extracted and combined from several patches ] Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Grant Likely <grant.likely@linaro.org> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Yingjoe Chen <yingjoe.chen@mediatek.com> Cc: Yijing Wang <wangyijing@huawei.com> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 Jiang Liu 提交于
Required to support non PCI based MSI. [ tglx: Extracted from Jiangs patch series ] Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
- 04 1月, 2014 1 次提交
-
-
由 Yinghai Lu 提交于
Convert pci/ioapic.c to be builtin only, with no module option, so we can support IO-APIC hotplug. Also make it depend on X86_IO_APIC. [bhelgaas: changelog] Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 12 8月, 2013 1 次提交
-
-
由 Thomas Petazzoni 提交于
Now that we have weak versions for each of the PCI MSI architecture functions, we can actually build the MSI support for all platforms, regardless of whether they provide or not architecture-specific versions of those functions. For this reason, the ARCH_SUPPORTS_MSI hidden kconfig boolean becomes useless, and this patch gets rid of it. Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Tested-by: NDaniel Price <daniel.price@gmail.com> Tested-by: NThierry Reding <thierry.reding@gmail.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: linuxppc-dev@lists.ozlabs.org Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: linux390@de.ibm.com Cc: linux-s390@vger.kernel.org Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: x86@kernel.org Cc: Russell King <linux@arm.linux.org.uk> Cc: Tony Luck <tony.luck@intel.com> Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: linux-ia64@vger.kernel.org Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Cc: David S. Miller <davem@davemloft.net> Cc: sparclinux@vger.kernel.org Cc: Chris Metcalf <cmetcalf@tilera.com> Signed-off-by: NJason Cooper <jason@lakedaemon.net>
-
- 04 6月, 2013 1 次提交
-
-
由 Stephen Rothwell 提交于
Ever since commit 45f035ab ("CONFIG_HOTPLUG should be always on"), it has been basically impossible to build a kernel with CONFIG_HOTPLUG turned off. Remove all the remaining references to it. Cc: Russell King <linux@arm.linux.org.uk> Cc: Doug Thompson <dougthompson@xmission.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Steven Whitehouse <swhiteho@redhat.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Pavel Machek <pavel@ucw.cz> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au> Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com> Acked-by: NHans Verkuil <hans.verkuil@cisco.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 21 5月, 2013 1 次提交
-
-
由 Thomas Petazzoni 提交于
This driver implements the support for the PCIe interfaces on the Marvell Armada 370/XP ARM SoCs. In the future, it might be extended to cover earlier families of Marvell SoCs, such as Dove, Orion and Kirkwood. The driver implements the hw_pci operations needed by the core ARM PCI code to setup PCI devices and get their corresponding IRQs, and the pci_ops operations that are used by the PCI core to read/write the configuration space of PCI devices. Since the PCIe interfaces of Marvell SoCs are completely separate and not linked together in a bus, this driver sets up an emulated PCI host bridge, with one PCI-to-PCI bridge as child for each hardware PCIe interface. In addition, this driver enumerates the different PCIe slots, and for those having a device plugged in, it sets up the necessary address decoding windows, using the mvebu-mbus driver. Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: NBjorn Helgaas <bhelgaas@google.com> Signed-off-by: NJason Cooper <jason@lakedaemon.net>
-
- 11 9月, 2012 1 次提交
-
-
由 Jan Beulich 提交于
Options without prompts and without dependencies don't usefully have a default value - they're intended to be selected from other options only. Signed-off-by: NJan Beulich <jbeulich@suse.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 25 2月, 2012 1 次提交
-
-
由 Yinghai Lu 提交于
Add a new config option, PCI_REALLOC_ENABLE_AUTO, which will automatically try to re-allocate PCI resources if PCI_IOV support is enabled and the SR-IOV resources are unassigned. Behavior can still be controlled using the pci=realloc= parameter. -v2: According to Jesse, adding one CONFIG option for distribution to disable it or enable it. -v3: update Kconfig text (jbarnes) Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 06 12月, 2011 1 次提交
-
-
由 Jan Beulich 提交于
This adjusts PCI_IOAPIC to be user configurable (possibly as a module) on x86, since the base architecture code for adding IO-APICs dynamically isn't there yet (and hence having the code present everywhere is pretty pointless). To make this consistent, a MODULE_DEVICE_TABLE() declaration gets added, the class specifications get corrected (by properly using PCI_DEVICE_CLASS() intended for purposes like this), and the probe and remove functions get their sections adjusted. Signed-off-by: NJan Beulich <jbeulich@suse.com> Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org> Cc: Bjorn Helgaas <bhelgaas@google.com> Link: http://lkml.kernel.org/r/4EDDD71A02000078000659F1@nat28.tlf.novell.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
-
- 01 11月, 2011 2 次提交
-
-
由 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>
-
由 Joerg Roedel 提交于
This avoids the PCI_PRI question in 'make config' when PCI is not selected. Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 15 10月, 2011 3 次提交
-
-
由 Joerg Roedel 提交于
Devices supporting Process Address Space Identifiers (PASIDs) can use an IOMMU to access multiple IO address spaces at the same time. A PCIe device indicates support for this feature by implementing the PASID capability. This patch adds support for the capability to the Linux kernel. Reviewed-by: NBjorn Helgaas <bhelgaas@google.com> Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Joerg Roedel 提交于
Implement the necessary functions to handle PRI capabilities on PCIe devices. With PRI devices behind an IOMMU can signal page fault conditions to software and recover from such faults. Reviewed-by: NBjorn Helgaas <bhelgaas@google.com> Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Joerg Roedel 提交于
ATS does not depend on IOV support, so move the code into its own file. This file will also include support for the PRI and PASID capabilities later. Also give ATS its own Kconfig variable to allow selecting it without IOV support. Reviewed-by: NBjorn Helgaas <bhelgaas@google.com> Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 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>
-