#
fa6dae5d |
|
19-May-2022 |
Hans de Goede <hdegoede@redhat.com> |
x86/PCI: Add kernel cmdline options to use/ignore E820 reserved regions Some firmware supplies PCI host bridge _CRS that includes address space unusable by PCI devices, e.g., space occupied by host bridge registers or used by hidden PCI devices. To avoid this unusable space, Linux currently excludes E820 reserved regions from _CRS windows; see 4dc2287c1805 ("x86: avoid E820 regions when allocating address space"). However, this use of E820 reserved regions to clip things out of _CRS is not supported by ACPI, UEFI, or PCI Firmware specs, and some systems have E820 reserved regions that cover the entire memory window from _CRS. 4dc2287c1805 clips the entire window, leaving no space for hot-added or uninitialized PCI devices. For example, from a Lenovo IdeaPad 3 15IIL 81WE: BIOS-e820: [mem 0x4bc50000-0xcfffffff] reserved pci_bus 0000:00: root bus resource [mem 0x65400000-0xbfffffff window] pci 0000:00:15.0: BAR 0: [mem 0x00000000-0x00000fff 64bit] pci 0000:00:15.0: BAR 0: no space for [mem size 0x00001000 64bit] Future patches will add quirks to enable/disable E820 clipping automatically. Add a "pci=no_e820" kernel command line option to disable clipping with E820 reserved regions. Also add a matching "pci=use_e820" option to enable clipping with E820 reserved regions if that has been disabled by default by further patches in this patch-set. Both options taint the kernel because they are intended for debugging and workaround purposes until a quirk can set them automatically. [bhelgaas: commit log, add printk] Link: https://bugzilla.redhat.com/show_bug.cgi?id=1868899 Lenovo IdeaPad 3 Link: https://lore.kernel.org/r/20220519152150.6135-2-hdegoede@redhat.com Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Benoit Grégoire <benoitg@coeus.ca> Cc: Hui Wang <hui.wang@canonical.com>
|
#
06dc660e |
|
13-Sep-2021 |
Oliver O'Halloran <oohall@gmail.com> |
PCI: Rename pcibios_add_device() to pcibios_device_add() The general convention for pcibios_* hooks is that they're named after the corresponding pci_* function they provide a hook for. The exception is pcibios_add_device() which provides a hook for pci_device_add(). Rename pcibios_add_device() to pcibios_device_add() so it matches pci_device_add(). Also, remove the export of the microblaze version. The only caller must be compiled as a built-in so there's no reason for the export. Link: https://lore.kernel.org/r/20210913152709.48013-1-oohall@gmail.com Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Niklas Schnelle <schnelle@linux.ibm.com> # s390
|
#
2c681e6b |
|
26-Aug-2020 |
Thomas Gleixner <tglx@linutronix.de> |
x86/pci: Set default irq domain in pcibios_add_device() Now that interrupt remapping sets the irqdomain pointer when a PCI device is added it's possible to store the default irq domain in the device struct in pcibios_add_device(). If the bus to which a device is connected has an irq domain associated then this domain is used otherwise the default domain (PCI/MSI native or XEN PCI/MSI) is used. Using the bus domain ensures that special MSI bus domains like VMD work. This makes XEN and the non-remapped native case work solely based on the irq domain pointer in struct device for PCI/MSI and allows to remove the arch fallback and make most of the x86_msi ops private to XEN in the next steps. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20200826112333.900423047@linutronix.de
|
#
dab01984 |
|
21-Jan-2020 |
Christoph Hellwig <hch@lst.de> |
x86/PCI: Remove X86_DEV_DMA_OPS There are no users of X86_DEV_DMA_OPS left, so remove the code. Link: https://lore.kernel.org/r/1579613871-301529-8-git-send-email-jonathan.derrick@intel.com Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jon Derrick <jonathan.derrick@intel.com>
|
#
2856ba60 |
|
21-Jan-2020 |
Jon Derrick <jonathan.derrick@intel.com> |
PCI: Introduce pci_real_dma_dev() The current DMA alias implementation requires the aliased device be on the same PCI bus as the requester ID. Add an arch-specific mechanism to point to another PCI device when doing mapping and PCI DMA alias search. The default case returns the actual device. Link: https://lore.kernel.org/r/1579613871-301529-4-git-send-email-jonathan.derrick@intel.com Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Christoph Hellwig <hch@lst.de>
|
#
c9c13ba4 |
|
27-Sep-2019 |
Denis Efremov <efremov@linux.com> |
PCI: Add PCI_STD_NUM_BARS for the number of standard BARs Code that iterates over all standard PCI BARs typically uses PCI_STD_RESOURCE_END. However, that requires the unusual test "i <= PCI_STD_RESOURCE_END" rather than something the typical "i < PCI_STD_NUM_BARS". Add a definition for PCI_STD_NUM_BARS and change loops to use the more idiomatic C style to help avoid fencepost errors. Link: https://lore.kernel.org/r/20190927234026.23342-1-efremov@linux.com Link: https://lore.kernel.org/r/20190927234308.23935-1-efremov@linux.com Link: https://lore.kernel.org/r/20190916204158.6889-3-efremov@linux.com Signed-off-by: Denis Efremov <efremov@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Sebastian Ott <sebott@linux.ibm.com> # arch/s390/ Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> # video/fbdev/ Acked-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com> # pci/controller/dwc/ Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com> # scsi/pm8001/ Acked-by: Martin K. Petersen <martin.petersen@oracle.com> # scsi/pm8001/ Acked-by: Ulf Hansson <ulf.hansson@linaro.org> # memstick/
|
#
457c8996 |
|
19-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Add SPDX license identifier for missed files Add SPDX license identifiers to all files which: - Have no license information of any form - Have EXPORT_.*_SYMBOL_GPL inside which was used in the initial scan/conversion to ignore the file These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
11eb0e0e |
|
04-Jun-2018 |
Sinan Kaya <okaya@codeaurora.org> |
PCI: Make early dump functionality generic Move early dump functionality into common code so that it is available for all architectures. No need to carry arch-specific reads around as the read hooks are already initialized by the time pci_setup_device() is getting called during scan. Tested-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Sinan Kaya <okaya@codeaurora.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
|
#
f32ab754 |
|
11-Jan-2018 |
=?UTF-8?q?Christian=20K=C3=B6nig?= <ckoenig.leichtzumerken@gmail.com> |
x86/PCI: Add "pci=big_root_window" option for AMD 64-bit windows Only try to enable a 64-bit window on AMD CPUs when "pci=big_root_window" is specified. This taints the kernel because the new 64-bit window uses address space we don't know anything about, and it may contain unreported devices or memory that would conflict with the window. The pci_amd_enable_64bit_bar() quirk that enables the window is specific to AMD CPUs. The generic solution would be to have the firmware enable the window and describe it in the host bridge's _CRS method, or at least describe it in the _PRS method so the OS would have the option of enabling it. Signed-off-by: Christian König <christian.koenig@amd.com> [bhelgaas: changelog, extend doc, mention taint in dmesg] Signed-off-by: Bjorn Helgaas <helgaas@kernel.org>
|
#
f7750a79 |
|
17-Jul-2017 |
Tom Lendacky <thomas.lendacky@amd.com> |
x86, mpparse, x86/acpi, x86/PCI, x86/dmi, SFI: Use memremap() for RAM mappings The ioremap() function is intended for mapping MMIO. For RAM, the memremap() function should be used. Convert calls from ioremap() to memremap() when re-mapping RAM. This will be used later by SME to control how the encryption mask is applied to memory mappings, with certain memory locations being mapped decrypted vs encrypted. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Borislav Petkov <bp@suse.de> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Borislav Petkov <bp@alien8.de> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Dave Young <dyoung@redhat.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Larry Woodman <lwoodman@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Rik van Riel <riel@redhat.com> Cc: Toshimitsu Kani <toshi.kani@hpe.com> Cc: kasan-dev@googlegroups.com Cc: kvm@vger.kernel.org Cc: linux-arch@vger.kernel.org Cc: linux-doc@vger.kernel.org Cc: linux-efi@vger.kernel.org Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/b13fccb9abbd547a7eef7b1fdfc223431b211c88.1500319216.git.thomas.lendacky@amd.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
#
df65c1bc |
|
16-Mar-2017 |
Thomas Gleixner <tglx@linutronix.de> |
x86/PCI: Select CONFIG_PCI_LOCKLESS_CONFIG All x86 PCI configuration space accessors have either their own serialization or can operate completely lockless (ECAM). Disable the global lock in the generic PCI configuration space accessors. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Bjorn Helgaas <helgaas@kernel.org> Cc: Andi Kleen <ak@linux.intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Borislav Petkov <bp@alien8.de> Cc: linux-pci@vger.kernel.org Link: http://lkml.kernel.org/r/20170316215057.295079391@linutronix.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
f5ab3b70 |
|
02-Jun-2017 |
Jean Delvare <jdelvare@suse.de> |
x86/PCI: Simplify Dell DMI B1 quirk No need for such convoluted code, when all we need is to call one function in one specific case. Tested-by: Narendra K <Narendra.K@dell.com> # DellEMC PowerEdge 1950, R730XD Signed-off-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
153654db |
|
28-Feb-2017 |
Rui Wang <rui.y.wang@intel.com> |
x86/PCI: Implement pcibios_release_device to release IRQ from IOAPIC The revert of 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()") causes a problem for IOAPIC hotplug. The problem is that IRQs are allocated and freed in pci_enable_device() and pci_disable_device(). But there are some drivers which don't call pci_disable_device(), and they have good reasons not calling it, so if they're using IOAPIC their IRQs won't have a chance to be released from the IOAPIC. When this happens IOAPIC hot-removal fails with a kernel stack dump and an error message like this: [149335.697989] pin16 on IOAPIC2 is still in use. It turns out that we can fix it in a different way without moving IRQ allocation into pcibios_alloc_irq(), thus avoiding the regression of 991de2e59090. We can keep the allocation and freeing of IRQs as is within pci_enable_device()/pci_disable_device(), without breaking any previous assumption of the rest of the system, keeping compatibility with both the legacy and the modern drivers. We can accomplish this by implementing the existing __weak hook of pcibios_release_device() thus when a pci device is about to be deleted we get notified in the hook and take the chance to release its IRQ, if any, from the IOAPIC. Implement pcibios_release_device() for x86 to release any IRQ not released by the driver. Signed-off-by: Rui Wang <rui.y.wang@intel.com> Cc: tony.luck@intel.com Cc: linux-pci@vger.kernel.org Cc: rjw@rjwysocki.net Cc: linux-acpi@vger.kernel.org Cc: fengguang.wu@intel.com Cc: helgaas@kernel.org Cc: kbuild-all@01.org Cc: bhelgaas@google.com Link: http://lkml.kernel.org/r/1488288869-31290-2-git-send-email-rui.y.wang@intel.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
5657933d |
|
20-Jan-2017 |
Bart Van Assche <bvanassche@acm.org> |
treewide: Move dma_ops from struct dev_archdata into struct device Some but not all architectures provide set_dma_ops(). Move dma_ops from struct dev_archdata into struct device such that it becomes possible on all architectures to configure dma_ops per device. Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Juergen Gross <jgross@suse.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: linux-arch@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Russell King <linux@armlinux.org.uk> Cc: x86@kernel.org Signed-off-by: Doug Ledford <dledford@redhat.com>
|
#
3161832d |
|
13-Sep-2016 |
Keith Busch <kbusch@kernel.org> |
x86/PCI: VMD: Request userspace control of PCIe hotplug indicators Add set_dev_domain_options() to set PCI domain-specific options as devices are added. The first usage is to request exclusive userspace control of PCIe hotplug indicators in VMD domains. Devices in a VMD domain use PCIe hotplug Attention and Power Indicators in a non-standard way; tell pciehp to ignore the indicators so userspace can control them via the sysfs "attention" file. To determine whether a bus is within a VMD domain, add a bool to the pci_sysdata structure that the VMD driver sets during initialization. [bhelgaas: changelog] Requested-by: Kapil Karkra <kapil.karkra@intel.com> Tested-by: Artur Paszkiewicz <artur.paszkiewicz@intel.com> Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
386ed2ab |
|
10-Jun-2016 |
Andrea Gelmini <andrea.gelmini@gelma.net> |
PCI: Fix comment typo Fix typo. Signed-off-by: Andrea Gelmini <andrea.gelmini@gelma.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
35a6ae07 |
|
23-Mar-2016 |
Adrian-Ken Rueegsegger <ken@codelabs.ch> |
x86/PCI: Refine PCI support check in pcibios_init() Also consider raw_pci_ext_ops when validating if a system has PCI support. This leads to proper resource allocation via pcibios_resource_survey() in the case where PCI config space is exclusively accessed through MMCONFIG. Signed-off-by: Adrian-Ken Rueegsegger <ken@codelabs.ch> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
6c777e87 |
|
16-Feb-2016 |
Bjorn Helgaas <bhelgaas@google.com> |
Revert "PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()" 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()") appeared in v4.3 and helps support IOAPIC hotplug. Олег reported that the Elcus-1553 TA1-PCI driver worked in v4.2 but not v4.3 and bisected it to 991de2e59090. Sunjin reported that the RocketRAID 272x driver worked in v4.2 but not v4.3. In both cases booting with "pci=routirq" is a workaround. I think the problem is that after 991de2e59090, we no longer call pcibios_enable_irq() for upstream bridges. Prior to 991de2e59090, when a driver called pci_enable_device(), we recursively called pcibios_enable_irq() for upstream bridges via pci_enable_bridge(). After 991de2e59090, we call pcibios_enable_irq() from pci_device_probe() instead of the pci_enable_device() path, which does *not* call pcibios_enable_irq() for upstream bridges. Revert 991de2e59090 to fix these driver regressions. Link: https://bugzilla.kernel.org/show_bug.cgi?id=111211 Fixes: 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()") Reported-and-tested-by: Олег Мороз <oleg.moroz@mcc.vniiem.ru> Reported-by: Sunjin Yang <fan4326@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael@kernel.org> CC: Jiang Liu <jiang.liu@linux.intel.com>
|
#
fe25d078 |
|
16-Feb-2016 |
Bjorn Helgaas <bhelgaas@google.com> |
Revert "x86/PCI: Don't alloc pcibios-irq when MSI is enabled" Revert 8affb487d4a4 ("x86/PCI: Don't alloc pcibios-irq when MSI is enabled"). This is part of reverting 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()") to fix regressions it introduced. Link: https://bugzilla.kernel.org/show_bug.cgi?id=111211 Fixes: 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()") Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael@kernel.org> CC: Jiang Liu <jiang.liu@linux.intel.com> CC: Joerg Roedel <jroedel@suse.de>
|
#
5bd28338 |
|
05-Feb-2016 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Remove includes of empty asm-generic/pci-bridge.h include/asm-generic/pci-bridge.h is now empty, so remove every #include of it. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Will Deacon <will.deacon@arm.com> (arm64)
|
#
d9c3d6ff |
|
12-Jan-2016 |
Keith Busch <kbusch@kernel.org> |
x86/PCI: Allow DMA ops specific to a PCI domain The Intel Volume Management Device (VMD) is a PCIe endpoint that acts as a host bridge to another PCI domain. When devices below the VMD perform DMA, the VMD replaces their DMA source IDs with its own source ID. Therefore, those devices require special DMA ops. Add interfaces to allow the VMD driver to set up dma_ops for the devices below it. [bhelgaas: remove "extern", add "static", changelog] Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
8affb487 |
|
08-Oct-2015 |
Joerg Roedel <jroedel@suse.de> |
x86/PCI: Don't alloc pcibios-irq when MSI is enabled The pcibios-irq and MSI both use dev->irq to store the IRQ number. While the MSI code checks for that and frees the pcibios-irq before overwriting dev->irq, the pcibios_alloc_irq() function does not. Usually this is not a problem, as the pcibios-irq is allocated before probe time of the device and the MSI IRQ is allocted from the driver's probe path. But there are PCI devices handled by the core kernel and not by a standard PCI driver, like the AMD IOMMU for example. For the AMD IOMMU a normal PCI device driver does not make sense, because a driver can be forcibly unbound from its device, which is not a good idea for an IOMMU. Nevertheless the PCI core code tries to match the PCI device implementing the AMD IOMMU against drivers, and allocates/frees a pcibios IRQ every time it tries out a new driver. This overwrites the dev->irq field set by pci_enable_msi() and sets it to 0 in the end (because the probe fails and the pcibios-irq is freed again). On suspend/resume this breaks the kernel, because the IRQ descriptor for IRQ 0 is NULL. Fix this by not allocating a pcibios-irq when MSI is already active. This also has the benefit, that a device claimed by the core kernel can not be probed by a PCI driver later. Reported-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Cc: Jiang Liu <jiang.liu@linux.intel.com>
|
#
237865f1 |
|
15-Sep-2015 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Revert "PCI: Call pci_read_bridge_bases() from core instead of arch code" Revert dff22d2054b5 ("PCI: Call pci_read_bridge_bases() from core instead of arch code"). Reading PCI bridge windows is not arch-specific in itself, but there is PCI core code that doesn't work correctly if we read them too early. For example, Hannes found this case on an ARM Freescale i.mx6 board: pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff] pci 0000:00:00.0: PCI bridge to [bus 01-ff] pci 0000:00:00.0: BAR 8: no space for [mem size 0x01000000] (mem window) pci 0000:01:00.0: BAR 2: failed to assign [mem size 0x00200000] pci 0000:01:00.0: BAR 1: failed to assign [mem size 0x00004000] pci 0000:01:00.0: BAR 0: failed to assign [mem size 0x00000100] The 00:00.0 mem window needs to be at least 3MB: the 01:00.0 device needs 0x204100 of space, and mem windows are megabyte-aligned. Bus sizing can increase a bridge window size, but never *decrease* it (see d65245c3297a ("PCI: don't shrink bridge resources")). Prior to dff22d2054b5, ARM didn't read bridge windows at all, so the "original size" was zero, and we assigned a 3MB window. After dff22d2054b5, we read the bridge windows before sizing the bus. The firmware programmed a 16MB window (size 0x01000000) in 00:00.0, and since we never decrease the size, we kept 16MB even though we only needed 3MB. But 16MB doesn't fit in the host bridge aperture, so we failed to assign space for the window and the downstream devices. I think this is a defect in the PCI core: we shouldn't rely on the firmware to assign sensible windows. Ray reported a similar problem, also on ARM, with Broadcom iProc. Issues like this are too hard to fix right now, so revert dff22d2054b5. Reported-by: Hannes <oe5hpm@gmail.com> Reported-by: Ray Jui <rjui@broadcom.com> Link: http://lkml.kernel.org/r/CAAa04yFQEUJm7Jj1qMT57-LG7ZGtnhNDBe=PpSRa70Mj+XhW-A@mail.gmail.com Link: http://lkml.kernel.org/r/55F75BB8.4070405@broadcom.com Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
|
#
991de2e5 |
|
10-Jun-2015 |
Jiang Liu <jiang.liu@linux.intel.com> |
PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq() To support IOAPIC hotplug, we need to allocate PCI IRQ resources on demand and free them when not used anymore. Implement pcibios_alloc_irq() and pcibios_free_irq() to dynamically allocate and free PCI IRQs. Remove mp_should_keep_irq(), which is no longer used. [bhelgaas: changelog] Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Thomas Gleixner <tglx@linutronix.de>
|
#
dff22d20 |
|
09-Jul-2015 |
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> |
PCI: Call pci_read_bridge_bases() from core instead of arch code When we scan a PCI bus, we read PCI-PCI bridge window registers with pci_read_bridge_bases() so we can validate the resource hierarchy. Most architectures call pci_read_bridge_bases() from pcibios_fixup_bus(), but PCI-PCI bridges are not arch-specific, so this doesn't need to be in arch-specific code. Call pci_read_bridge_bases() directly from the PCI core instead of from arch code. For alpha and mips, we now call pci_read_bridge_bases() always; previously we only called it if PCI_PROBE_ONLY was set. [bhelgaas: changelog] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Ralf Baechle <ralf@linux-mips.org> CC: James E.J. Bottomley <jejb@parisc-linux.org> CC: Michael Ellerman <mpe@ellerman.id.au> CC: Bjorn Helgaas <bhelgaas@google.com> CC: Richard Henderson <rth@twiddle.net> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> CC: David Howells <dhowells@redhat.com> CC: Russell King <linux@arm.linux.org.uk> CC: Tony Luck <tony.luck@intel.com> CC: David S. Miller <davem@davemloft.net> CC: Ingo Molnar <mingo@redhat.com> CC: Guenter Roeck <linux@roeck-us.net> CC: Michal Simek <monstr@monstr.eu> CC: Chris Zankel <chris@zankel.net>
|
#
9e8ce4b9 |
|
20-Mar-2015 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
Revert "x86/PCI: Refine the way to release PCI IRQ resources" Commit b4b55cda5874 (Refine the way to release PCI IRQ resources) introduced a regression in the PCI IRQ resource management by causing the IRQ resource of a device, established when pci_enabled_device() is called on a fully disabled device, to be released when the driver is unbound from the device, regardless of the enable_cnt. This leads to the situation that an ill-behaved driver can now make a device unusable to subsequent drivers by an imbalance in their use of pci_enable/disable_device(). That is a serious problem for secondary drivers like vfio-pci, which are innocent of the transgressions of the previous driver. Since the solution of this problem is not immediate and requires further discussion, revert commit b4b55cda5874 and the issue it was supposed to address (a bug related to xen-pciback) will be taken care of in a different way going forward. Reported-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
b97ea289 |
|
15-Mar-2015 |
Yijing Wang <wangyijing@huawei.com> |
PCI: Assign resources before drivers claim devices (pci_scan_root_bus()) Previously, pci_scan_root_bus() created a root PCI bus, enumerated the devices on it, and called pci_bus_add_devices(), which made the devices available for drivers to claim them. Most callers assigned resources to devices after pci_scan_root_bus() returns, which may be after drivers have claimed the devices. This is incorrect; the PCI core should not change device resources while a driver is managing the device. Remove pci_bus_add_devices() from pci_scan_root_bus() and do it after any resource assignment in the callers. Note that ARM's pci_common_init_dev() already called pci_bus_add_devices() after pci_scan_root_bus(), so we only need to remove the first call: pci_common_init_dev pcibios_init_hw pci_scan_root_bus pci_bus_add_devices # first call pci_bus_assign_resources pci_bus_add_devices # second call [bhelgaas: changelog, drop "root_bus" var in alpha common_init_pci(), return failure earlier in mn10300, add "return" in x86 pcibios_scan_root(), return early if xtensa platform_pcibios_fixup() fails] Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Richard Henderson <rth@twiddle.net> CC: Ivan Kokshaysky <ink@jurassic.park.msu.ru> CC: Matt Turner <mattst88@gmail.com> CC: David Howells <dhowells@redhat.com> CC: Tony Luck <tony.luck@intel.com> CC: Michal Simek <monstr@monstr.eu> CC: Ralf Baechle <ralf@linux-mips.org> CC: Koichi Yasutake <yasutake.koichi@jp.panasonic.com> CC: Sebastian Ott <sebott@linux.vnet.ibm.com> CC: "David S. Miller" <davem@davemloft.net> CC: Chris Metcalf <cmetcalf@ezchip.com> CC: Chris Zankel <chris@zankel.net> CC: Max Filippov <jcmvbkbc@gmail.com> CC: Thomas Gleixner <tglx@linutronix.de>
|
#
b4b55cda |
|
04-Feb-2015 |
Jiang Liu <jiang.liu@linux.intel.com> |
x86/PCI: Refine the way to release PCI IRQ resources Some PCI device drivers assume that pci_dev->irq won't change after calling pci_disable_device() and pci_enable_device() during suspend and resume. Commit c03b3b0738a5 ("x86, irq, mpparse: Release IOAPIC pin when PCI device is disabled") frees PCI IRQ resources when pci_disable_device() is called and reallocate IRQ resources when pci_enable_device() is called again. This breaks above assumption. So commit 3eec595235c1 ("x86, irq, PCI: Keep IRQ assignment for PCI devices during suspend/hibernation") and 9eabc99a635a ("x86, irq, PCI: Keep IRQ assignment for runtime power management") fix the issue by avoiding freeing/reallocating IRQ resources during PCI device suspend/resume. They achieve this by checking dev.power.is_prepared and dev.power.runtime_status. PM maintainer, Rafael, then pointed out that it's really an ugly fix which leaking PM internal state information to IRQ subsystem. Recently David Vrabel <david.vrabel@citrix.com> also reports an regression in pciback driver caused by commit cffe0a2b5a34 ("x86, irq: Keep balance of IOAPIC pin reference count"). Please refer to: http://lkml.org/lkml/2015/1/14/546 So this patch refine the way to release PCI IRQ resources. Instead of releasing PCI IRQ resources in pci_disable_device()/ pcibios_disable_device(), we now release it at driver unbinding notification BUS_NOTIFY_UNBOUND_DRIVER. In other word, we only release PCI IRQ resources when there's no driver bound to the PCI device, and it keeps the assumption that pci_dev->irq won't through multiple invocation of pci_enable_device()/pci_disable_device(). Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
51ac3d2f |
|
02-Feb-2015 |
Charlotte Richardson <charlotte.richardson@stratus.com> |
PCI: Add NEC variants to Stratus ftServer PCIe DMI check NEC OEMs the same platforms as Stratus does, which have multiple devices on some PCIe buses under downstream ports. Link: https://bugzilla.kernel.org/show_bug.cgi?id=51331 Fixes: 1278998f8ff6 ("PCI: Work around Stratus ftServer broken PCIe hierarchy (fix DMI check)") Signed-off-by: Charlotte Richardson <charlotte.richardson@stratus.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.5+ CC: Myron Stowe <myron.stowe@redhat.com>
|
#
4ac9cbfa |
|
25-Aug-2014 |
Mathias Krause <minipli@googlemail.com> |
x86/PCI: Mark DMI tables as initialization data The DMI tables are only used in __init code, thereby can be marked as initialization data, too. The same is true for the callback functions referenced from the DMI tables. This moves ~9.6 kB of code and r/o data to the init sections, marking the memory for release after initialization. Signed-off-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Ingo Molnar <mingo@kernel.org>
|
#
c5f9ee3d |
|
25-Feb-2014 |
H. Peter Anvin <hpa@linux.intel.com> |
x86, platforms: Remove SGI Visual Workstation The SGI Visual Workstation seems to be dead; remove support so we don't have to continue maintaining it. Cc: Andrey Panin <pazke@donpac.ru> Cc: Michael Reed <mdr@sgi.com> Link: http://lkml.kernel.org/r/530CFD6C.7040705@zytor.com Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
|
#
25453e9e |
|
24-Jan-2014 |
Bjorn Helgaas <bhelgaas@google.com> |
x86/PCI: Remove mp_bus_to_node[], set_mp_bus_to_node(), get_mp_bus_to_node() There are no callers of get_mp_bus_to_node(), so we no longer need mp_bus_to_node[], get_mp_bus_to_node(), or set_mp_bus_to_node(). This removes them. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
6616dbdf |
|
24-Jan-2014 |
Bjorn Helgaas <bhelgaas@google.com> |
x86/PCI: Use x86_pci_root_bus_node() instead of get_mp_bus_to_node() This replaces all uses of get_mp_bus_to_node() with x86_pci_root_bus_node(). I think these uses are all on root buses, except possibly for blind probing, where NUMA node information is unimportant. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
49886cf4 |
|
28-Jan-2014 |
Bjorn Helgaas <bhelgaas@google.com> |
x86/PCI: Drop return value of pcibios_scan_root() Nobody really uses the return value of pcibios_scan_root() (one place uses it to control a printk, but the printk is not very useful). This converts pcibios_scan_root() to a void function. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
289a24a6 |
|
24-Jan-2014 |
Bjorn Helgaas <bhelgaas@google.com> |
x86/PCI: Merge pci_scan_bus_on_node() into pcibios_scan_root() pci_scan_bus_on_node() is only called by pcibios_scan_root(). This merges pci_scan_bus_on_node() into pcibios_scan_root() and removes pci_scan_bus_on_node(). Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
8d7d8186 |
|
24-Jan-2014 |
Bjorn Helgaas <bhelgaas@google.com> |
x86/PCI: Use pcibios_scan_root() instead of pci_scan_bus_with_sysdata() pci_scan_bus_with_sysdata() and pcibios_scan_root() are quite similar: pci_scan_bus_with_sysdata pci_scan_bus_on_node(..., &pci_root_ops, -1) pcibios_scan_root pci_scan_bus_on_node(..., &pci_root_ops, get_mp_bus_to_node(busnum)) get_mp_bus_to_node() returns -1 if it couldn't find the node number, so this removes pci_scan_bus_with_sysdata() and uses pcibios_scan_root() instead. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
f19e8482 |
|
28-Jan-2014 |
Bjorn Helgaas <bhelgaas@google.com> |
x86/PCI: Drop pcibios_scan_root() check for bus already scanned The PCI core checks to see whether we've already scanned a bus, so we don't need to do it in pcibios_scan_root(). Here's where it happens in the core: pcibios_scan_root pci_scan_bus_on_node pci_scan_root_bus pci_create_root_bus b2 = pci_find_bus(pci_domain_nr(b), bus) if (b2) goto err_out; # already scanned this bus This removes the check from pcibios_scan_root(). Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
65694c5a |
|
05-Jun-2013 |
Matt Fleming <matt.fleming@intel.com> |
x86/PCI: Map PCI setup data with ioremap() so it can be in highmem f9a37be0f0 ("x86: Use PCI setup data") added support for using PCI ROM images from setup_data. This used phys_to_virt(), which is not valid for highmem addresses, and can cause a crash when booting a 32-bit kernel via the EFI boot stub. pcibios_add_device() assumes that the physical addresses stored in setup_data are accessible via the direct kernel mapping, and that calling phys_to_virt() is valid. This isn't guaranteed to be true on x86 where the direct mapping range is much smaller than on x86-64. Calling phys_to_virt() on a highmem address results in the following: BUG: unable to handle kernel paging request at 39a3c198 IP: [<c262be0f>] pcibios_add_device+0x2f/0x90 ... Call Trace: [<c2370c73>] pci_device_add+0xe3/0x130 [<c274640b>] pci_scan_single_device+0x8b/0xb0 [<c2370d08>] pci_scan_slot+0x48/0x100 [<c2371904>] pci_scan_child_bus+0x24/0xc0 [<c262a7b0>] pci_acpi_scan_root+0x2c0/0x490 [<c23b7203>] acpi_pci_root_add+0x312/0x42f ... The solution is to use ioremap() instead of phys_to_virt() to map the setup data into the kernel address space. [bhelgaas: changelog] Tested-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Seth Forshee <seth.forshee@canonical.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: stable@vger.kernel.org # v3.8+
|
#
89016506 |
|
11-Apr-2013 |
Jiang Liu <liuj97@gmail.com> |
x86/PCI: Implement pcibios_{add|remove}_bus() hooks Implement pcibios_{add|remove}_bus() hooks for x86 platforms. Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Yinghai Lu <yinghai@kernel.org> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Cc: Toshi Kani <toshi.kani@hp.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Myron Stowe <myron.stowe@redhat.com>
|
#
a18e3690 |
|
21-Dec-2012 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
X86: drivers: remove __dev* attributes. CONFIG_HOTPLUG is going away as an option. As a result, the __dev* markings need to be removed. This change removes the use of __devinit, __devexit_p, __devinitconst, and __devexit from these drivers. Based on patches originally written by Bill Pemberton, but redone by me in order to handle some of the coding style issues better, by hand. Cc: Bill Pemberton <wfp5p@virginia.edu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Daniel Drake <dsd@laptop.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
b7869ba1 |
|
03-Jan-2013 |
Bjorn Helgaas <bhelgaas@google.com> |
x86/PCI: Remove unused pci_root_bus pci_root_bus is unused, so remove all references to it. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
1278998f |
|
26-Dec-2012 |
Myron Stowe <myron.stowe@redhat.com> |
PCI: Work around Stratus ftServer broken PCIe hierarchy (fix DMI check) Commit 284f5f9 was intended to disable the "only_one_child()" optimization on Stratus ftServer systems, but its DMI check is wrong. It looks for DMI_SYS_VENDOR that contains "ftServer", when it should look for DMI_SYS_VENDOR containing "Stratus" and DMI_PRODUCT_NAME containing "ftServer". Tested on Stratus ftServer 6400. Reported-by: Fadeeva Marina <astarta@rat.ru> Reference: https://bugzilla.kernel.org/show_bug.cgi?id=51331 Signed-off-by: Myron Stowe <myron.stowe@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.5+
|
#
dbd3fc33 |
|
10-Dec-2012 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: Use phys_addr_t for physical ROM address Use phys_addr_t rather than "void *" for physical memory address. This removes casts and fixes a "cast from pointer to integer of different size" warning on ppc44x_defconfig. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
f9a37be0 |
|
05-Dec-2012 |
Matthew Garrett <mjg@redhat.com> |
x86: Use PCI setup data EFI can provide PCI ROMs out of band via boot services, which may not be available after boot. Add support for using the data handed off to us by the boot stub or bootloader. [bhelgaas: added Seth's boot_params section mismatch fix] [bhelgaas: drop "boot_params.hdr.version < 0x0209" test] Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Seth Forshee <seth.forshee@canonical.com>
|
#
642c92da |
|
30-Oct-2012 |
Taku Izumi <izumi.taku@jp.fujitsu.com> |
PCI: Don't pass pci_dev to pci_ext_cfg_avail() pci_ext_cfg_avail() doesn't use the "struct pci_dev *" passed to it, and there's no requirement that a host bridge even be represented by a pci_dev. This drops the pci_ext_cfg_avail() parameter. [bhelgaas: changelog] Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
15fa325b |
|
25-Jun-2012 |
Myron Stowe <myron.stowe@redhat.com> |
x86/PCI: adjust section annotations for pcibios_setup() Make pcibios_setup() consistently use the "__init" section annotation. Signed-off-by: Myron Stowe <myron.stowe@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
284f5f9d |
|
30-Apr-2012 |
Bjorn Helgaas <bhelgaas@google.com> |
PCI: work around Stratus ftServer broken PCIe hierarchy A PCIe downstream port is a P2P bridge. Its secondary interface is a link that should lead only to device 0 (unless ARI is enabled)[1], so we don't probe for non-zero device numbers. Some Stratus ftServer systems have a PCIe downstream port (02:00.0) that leads to both an upstream port (03:00.0) and a downstream port (03:01.0), and 03:01.0 has important devices below it: [0000:02]-+-00.0-[03-3c]--+-00.0-[04-09]--... \-01.0-[0a-0d]--+-[USB] +-[NIC] +-... Previously, we didn't enumerate device 03:01.0, so USB and the network didn't work. This patch adds a DMI quirk to scan all device numbers, not just 0, below a downstream port. Based on a patch by Prarit Bhargava. [1] PCIe spec r3.0, sec 7.3.1 CC: Myron Stowe <mstowe@redhat.com> CC: Don Dutile <ddutile@redhat.com> CC: James Paradis <james.paradis@stratus.com> CC: Matthew Wilcox <matthew.r.wilcox@intel.com> CC: Jesse Barnes <jbarnes@virtuousgeek.org> CC: Prarit Bhargava <prarit@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
c57ca65a |
|
02-Apr-2012 |
Yinghai Lu <yinghai@kernel.org> |
x86/PCI: merge pcibios_scan_root() and pci_scan_bus_on_node() pcibios_scan_root() and pci_scan_bus_on_node() were almost identical, so this patch merges them. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
2cd6975a |
|
28-Oct-2011 |
Bjorn Helgaas <bhelgaas@google.com> |
x86/PCI: convert to pci_create_root_bus() and pci_scan_root_bus() x86 has two kinds of PCI root bus scanning: (1) ACPI-based, using _CRS resources. This used pci_create_bus(), not pci_scan_bus(), because ACPI hotplug needed to split the pci_bus_add_devices() into a separate host bridge .start() method. This patch parses the _CRS resources earlier, so we can build a list of resources and pass it to pci_create_root_bus(). Note that as before, we parse the _CRS even if we aren't going to use it so we can print it for debugging purposes. (2) All other, which used either default resources (ioport_resource and iomem_resource) or information read from the hardware via amd_bus.c or similar. This used pci_scan_bus(). This patch converts x86_pci_root_bus_res_quirks() (previously called from pcibios_fixup_bus()) to x86_pci_root_bus_resources(), which builds a list of resources before we call pci_scan_root_bus(). We also use x86_pci_root_bus_resources() if we have ACPI but are ignoring _CRS. CC: Yinghai Lu <yinghai.lu@oracle.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
46fbade0 |
|
28-Oct-2011 |
Bjorn Helgaas <bhelgaas@google.com> |
x86/PCI: use pci_scan_bus() instead of pci_scan_bus_parented() 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: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
72da0b07 |
|
15-Sep-2011 |
Jan Beulich <JBeulich@suse.com> |
x86: constify PCI raw ops structures 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: Ingo Molnar <mingo@elte.hu> Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
9b373ed1 |
|
18-Mar-2011 |
Narendra_K@Dell.com <Narendra_K@Dell.com> |
x86/PCI: Preserve existing pci=bfsort whitelist for Dell systems Commit 6e8af08dfa40b747002207d3ce8e8b43a050d99f 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: Shyam Iyer <shyam_iyer@dell.com> Signed-off-by: Narendra K <narendra_k@dell.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
6e8af08d |
|
14-Dec-2010 |
Narendra_K@Dell.com <Narendra_K@Dell.com> |
PCI: enable pci=bfsort by default on future Dell systems 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: Jordan Hargrave <jordan_hargrave@dell.com> Signed-off-by: Narendra K <narendra_k@dell.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
44de3395 |
|
18-Mar-2010 |
Alex Nixon <alex.nixon@citrix.com> |
x86/PCI: Clean up pci_cache_line_size 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: Alex Nixon <alex.nixon@citrix.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: "H. Peter Anvin" <hpa@zytor.com> Reviewed-by: Matthew Wilcox <willy@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: x86@kernel.org
|
#
7bd1c365 |
|
12-May-2010 |
Mike Habeck <habeck@sgi.com> |
x86/PCI: Add option to not assign BAR's if not already assigned 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: Mike Habeck <habeck@sgi.com> Signed-off-by: Mike Travis <travis@sgi.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
d19f61f0 |
|
17-Feb-2010 |
Thomas Gleixner <tglx@linutronix.de> |
x86/PCI: Convert pci_config_lock to raw_spinlock pci_config_lock must be a real spinlock in preempt-rt. Convert it to raw_spinlock. No change for !RT kernels. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
5a0e3ad6 |
|
24-Mar-2010 |
Tejun Heo <tj@kernel.org> |
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: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
|
#
7bc5e3f2 |
|
23-Feb-2010 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
x86/PCI: use host bridge _CRS info by default on 2008 and newer machines 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: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
b72d0db9 |
|
29-Aug-2009 |
Thomas Gleixner <tglx@linutronix.de> |
x86: Move pci init function to x86_init 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: Thomas Gleixner <tglx@linutronix.de> LKML-Reference: <43F901BD926A4E43B106BF17856F07559FB80CFE@orsmsx508.amr.corp.intel.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Jacob Pan <jacob.jun.pan@intel.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
#
76b1a87b |
|
14-Oct-2009 |
Dave Jones <davej@redhat.com> |
x86/PCI: Use generic cacheline sizing instead of per-vendor tests. 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: Dave Jones <davej@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
ac1aa47b |
|
26-Oct-2009 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
PCI: determine CLS more intelligently 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: Tejun Heo <tj@kernel.org> Acked-by: David Miller <davem@davemloft.net> Acked-by: Greg 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: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
76baeebf |
|
18-Sep-2009 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
x86/PCI: make 32 bit NUMA node array int, not unsigned char 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: Ingo Molnar <mingo@elte.hu> Tested-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
2547089c |
|
10-Jul-2009 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
x86/PCI: initialize PCI bus node numbers early 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: Yinghai Lu <yinghai@kernel.org> Tested-by: Jesse Brandeburg <jesse.brandeburg@gmail.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
236e946b |
|
24-Jun-2009 |
Linus Torvalds <torvalds@linux-foundation.org> |
Revert "PCI: use ACPI _CRS data by default" This reverts commit 9e9f46c44e487af0a82eb61b624553e2f7118f5b. 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: Linus Torvalds <torvalds@linux-foundation.org>
|
#
9e9f46c4 |
|
11-Jun-2009 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
PCI: use ACPI _CRS data by default 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: Yinghai Lu <yhlu.kernel@gmail.com> Acked-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
0e94ecd0 |
|
18-Apr-2009 |
Yinghai Lu <yinghai@kernel.org> |
x86/PCI: set_pci_bus_resources_arch_default cleanups 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: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
0bb1be3e |
|
16-Apr-2009 |
Matthew Wilcox <willy@infradead.org> |
x86/PCI: Move set_pci_bus_resources_arch_default into arch/x86 Commit 30a18d6c3f1e774de656ebd8ff219d53e2ba4029 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: Matthew Wilcox <willy@linux.intel.com> Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
821508d4 |
|
11-Mar-2009 |
Jan Beulich <jbeulich@novell.com> |
x86: move a few device initialization objects into .devinit.rodata 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: Jan Beulich <jbeulich@novell.com> LKML-Reference: <49B909A5.76E4.0078.0@novell.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
#
16cf0ebc |
|
05-Jan-2009 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
x86/PCI: Do not use interrupt links for devices using MSI-X 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: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
0ef5f8f6 |
|
10-Nov-2008 |
Andrew Patterson <andrew.patterson@hp.com> |
ACPI/PCI: PCI extended config _OSC support called when root bridge added 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: Andrew Patterson <andrew.patterson@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
82487711 |
|
27-Dec-2008 |
Jaswinder Singh Rajput <jaswinder@infradead.org> |
x86, pci: move arch/x86/pci/pci.h to arch/x86/include/asm/pci_x86.h 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: Jaswinder Singh Rajput <jaswinderrajput@gmail.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
#
41b9eb26 |
|
15-Jul-2008 |
Stefan Assmann <sassmann@suse.de> |
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: Stefan Assmann <sassmann@suse.de> Signed-off-by: Olaf 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: Ingo Molnar <mingo@elte.hu>
|
#
beef3129 |
|
11-Jul-2008 |
Matthew Wilcox <willy@infradead.org> |
x86/PCI: Fix PCI config space for domains > 0 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: John Keller <jpk@sgi.com> Signed-off-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
8dd779b1 |
|
02-Jul-2008 |
Robert Richter <robert.richter@amd.com> |
x86/pci: removing subsys_initcall ordering dependencies 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: Robert Richter <robert.richter@amd.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
#
9197979b |
|
11-Jun-2008 |
Stefan Assmann <sassmann@suse.de> |
x86, pci: introduce pci=ioapicreroute kernel cmdline option Introduce pci=ioapicreroute kernel cmdline option to enable rerouting of boot interrupts to the primary io-apic. Signed-off-by: Stefan Assmann <sassmann@suse.de> Signed-off-by: Olaf Dabrunz <od@suse.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
#
a9322f64 |
|
11-Jun-2008 |
Stefan Assmann <sassmann@suse.de> |
x86, pci: introduce pci=noioapicquirk kernel cmdline option Introduce pci=noioapicquirk kernel cmdline option to disable all boot interrupt quirks Signed-off-by: Stefan Assmann <sassmann@suse.de> Signed-off-by: Olaf Dabrunz <od@suse.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
#
739db07f |
|
07-Jul-2008 |
Jesse Barnes <jbarnes@hobbes.(none)> |
Revert "PCI: Correct last two HP entries in the bfsort whitelist" This reverts commit a1676072558854b95336c8f7db76b0504e909a0a. It duplicates the change from 8d64c781f0c5fbfdf8016bd1634506ff2ad1376a and only one should be applied, otherwise some of the Dell quirks are lost. Thanks to Tony Camuso for catching this. Acked-by: Tony Camuso <tcamuso@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
e3f2baeb |
|
22-May-2008 |
Yinghai Lu <yhlu.kernel@gmail.com> |
PCI/x86: early dump pci conf space v2 Allows us to dump PCI space before any kernel changes have been made. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
bb71ad88 |
|
12-May-2008 |
Gary Hade <garyhade@us.ibm.com> |
PCI: boot parameter to avoid expansion ROM memory allocation 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: Gary Hade <garyhade@us.ibm.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
a1676072 |
|
15-May-2008 |
Tony Camuso <tcamuso@redhat.com> |
PCI: Correct last two HP entries in the bfsort whitelist 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: Tony Camuso <tony.camuso@hp.com> Signed-off-by: Pat Schoeller <patrick.schoeller@hp.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
8d64c781 |
|
15-May-2008 |
Tony Camuso <tcamuso@redhat.com> |
PCI: Correct last two HP entries in the bfsort whitelist 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: Tony Camuso <tony.camuso@hp.com> Signed-off-by: Pat Schoeller <patrick.schoeller@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
8d539108 |
|
08-May-2008 |
Linus Torvalds <torvalds@linux-foundation.org> |
Revert "PCI: remove default PCI expansion ROM memory allocation" This reverts commit 9f8daccaa05c14e5643bdd4faf5aed9cc8e6f11e, 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: Laurence 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: Linus Torvalds <torvalds@linux-foundation.org>
|
#
0df18ff3 |
|
14-Apr-2008 |
Yinghai Lu <yhlu.kernel@gmail.com> |
x86 PCI: call dmi_check_pciprobe() this change: | commit 08f1c192c3c32797068bfe97738babb3295bbf42 | 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: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
13a6ddb0 |
|
27-Mar-2008 |
Yinghai Lu <yhlu.kernel.send@gmail.com> |
x86/pci: add pci=skip_isa_align command lines. 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: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
98db6f19 |
|
29-Apr-2008 |
Sam Ravnborg <sam@ravnborg.org> |
x86: fix section mismatch in pci_scan_bus 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: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Jesse Barnes <jbarnes@hobbes.lan>
|
#
5f0b2976 |
|
14-Apr-2008 |
Yinghai Lu <yhlu.kernel@gmail.com> |
x86: add pci=check_enable_amd_mmconf and dmi check 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: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
871d5f8d |
|
19-Feb-2008 |
Yinghai Lu <Yinghai.Lu@Sun.COM> |
x86: get mp_bus_to_node early 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: Yinghai Lu <yinghai.lu@sun.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
b81d988c |
|
04-Mar-2008 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
PCI: x86: use generic pci_enable_resources() 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: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
6355f3d1 |
|
14-Feb-2008 |
Greg Kroah-Hartman <gregkh@suse.de> |
PCI: remove pcibios_fixup_ghosts() 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: Greg Kroah-Hartman <gregkh@suse.de>
|
#
1ba6ab11 |
|
13-Feb-2008 |
Greg Kroah-Hartman <gregkh@suse.de> |
PCI: remove initial bios sort of PCI devices on x86 We currently keep 2 lists of PCI devices in the system, one in the driver core, and one all on its own. This second list is sorted at boot time, in "BIOS" order, to try to remain compatible with older kernels (2.2 and earlier days). There was also a "nosort" option to turn this sorting off, to remain compatible with even older kernel versions, but that just ends up being what we have been doing from 2.5 days... Unfortunately, the second list of devices is not really ever used to determine the probing order of PCI devices or drivers[1]. That is done using the driver core list instead. This change happened back in the early 2.5 days. Relying on BIOS ording for the binding of drivers to specific device names is problematic for many reasons, and userspace tools like udev exist to properly name devices in a persistant manner if that is needed, no reliance on the BIOS is needed. Matt Domsch and others at Dell noticed this back in 2006, and added a boot option to sort the PCI device lists (both of them) in a breadth-first manner to help remain compatible with the 2.4 order, if needed for any reason. This option is not going away, as some systems rely on them. This patch removes the sorting of the internal PCI device list in "BIOS" mode, as it's not needed at all anymore, and hasn't for many years. I've also removed the PCI flags for this from some other arches that for some reason defined them, but never used them. This should not change the ordering of any drivers or device probing. [1] The old-style pci_get_device and pci_find_device() still used this sorting order, but there are very few drivers that use these functions, as they are deprecated for use in this manner. If for some reason, a driver rely on the order and uses these functions, the breadth-first boot option will resolve any problem. Cc: Matt Domsch <Matt_Domsch@dell.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
6871b76f |
|
17-Feb-2008 |
Sam Ravnborg <sam@ravnborg.org> |
x86: annotate pci/common.s:pci_scan_bus_with_sysdata with __devinit Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
b6ce068a |
|
10-Feb-2008 |
Matthew Wilcox <willy@infradead.org> |
Change pci_raw_ops to pci_raw_read/write We want to allow different implementations of pci_raw_ops for standard and extended config space on x86. Rather than clutter generic code with knowledge of this, we make pci_raw_ops private to x86 and use it to implement the new raw interface -- raw_pci_read() and raw_pci_write(). Signed-off-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
9f8dacca |
|
30-Jan-2008 |
Gary Hade <garyhade@us.ibm.com> |
PCI: remove default PCI expansion ROM memory allocation 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 addresses the issue by changing the kernel default behavior so that expansion ROM memory allocations are no longer attempted by default when the BIOS has not assigned a specific address range to the expansion ROM BAR. This was done by changing the 'pci=rom' boot option behavior for BIOS unassigned expansion ROMs to actually match it's current kernel-parameters.txt description which already implies "off" by default. Behavior for BIOS assigned expansion ROMs implemented in pcibios_assign_resources() [arch/x86/pci/i386.c] is unchanged. Signed-off-by: Gary Hade <garyhade@us.ibm.com> Cc: Greg KH <greg@kroah.com> Cc: Jan Beulich <jbeulich@novell.com> Acked-by: "Jun'ichi Nomura" <j-nomura@ce.jp.nec.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
c82bc5ad |
|
26-Nov-2007 |
Michal Schmidt <mschmidt@redhat.com> |
pci: use pci=bfsort for HP DL385 G2, DL585 G2 HP ProLiant systems DL385 G2 and DL585 G2 need pci=bfsort to enumerate PCI devices in the expected order. Matt sayeth: biosdevname is a userspace app I wrote to help solve this so we don't need to patch the kernel for future systems. It's not integrated into any distributions properly yet, but is included in openSUSE 10.3 and Fedora 8 for people who want to download and install it there. It acts as a udev helper. For the time being, patching the kernel is necessary. I really hope biosdevname eliminates that need in future distributions. http://linux.dell.com/biosdevname/ Signed-off-by: Michal Schmidt <mschmidt@redhat.com> Acked-by: Andy Gospodarek <andy@greyhouse.net> Cc: mingo@elte.hu Cc: andy@greyhouse.net Cc: john.cagle@hp.com Cc: Matt Domsch <Matt_Domsch@dell.com> Cc: Greg KH <greg@kroah.com> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
#
8f8ae1a7 |
|
17-Oct-2007 |
Michal Schmidt <mschmidt@redhat.com> |
x86: pci use pci=bfsort for HP DL385 G2 and DL585 G2 HP ProLiant systems DL385 G2 and DL585 G2 need pci=bfsort to enumerate PCI devices in the expected order. Matt sayeth: biosdevname is a userspace app I wrote to help solve this so we don't need to patch the kernel for future systems. It's not integrated into any distributions properly yet, but is included in openSUSE 10.3 and Fedora 8 for people who want to download and install it there. It acts as a udev helper. For the time being, patching the kernel is necessary. I really hope biosdevname eliminates that need in future distributions. http://linux.dell.com/biosdevname/ Signed-off-by: Michal Schmidt <mschmidt@redhat.com> Cc: <john.cagle@hp.com> Cc: Matt Domsch <Matt_Domsch@dell.com> Cc: Andy Gospodarek <andy@greyhouse.net> Cc: Greg KH <greg@kroah.com> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
a79e4198 |
|
11-Oct-2007 |
Jeff Garzik <jeff@garzik.org> |
PCI: X86: Introduce and enable PCI domain support * fix bug in pci_read() and pci_write() which prevented PCI domain support from working (hardcoded domain 0). * unconditionally enable CONFIG_PCI_DOMAINS * implement pci_domain_nr() and pci_proc_domain(), as required of all arches when CONFIG_PCI_DOMAINS is enabled. * store domain in struct pci_sysdata, as assigned by ACPI * support "pci=nodomains" Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
62f420f8 |
|
03-Oct-2007 |
Gary Hade <garyhade@us.ibm.com> |
PCI: use _CRS for PCI resource allocation Use _CRS for PCI resource allocation This patch resolves an issue where incorrect PCI memory and i/o ranges are being assigned to hotplugged PCI devices on some IBM systems. The resource mis-allocation not only makes the PCI device unuseable but often makes the entire system unuseable due to resulting machine checks. The hotplug capable PCI slots on the affected systems are not located under a standard P2P bridge but are instead located under PCI root bridges or subtractive decode P2P bridges. For example, the IBM x3850 contains 2 hotplug capable PCI-X slots and 4 hotplug capable PCIe slots with the PCI-X slots each located under a PCI root bridge and the PCIe slots each located under a subtractive decode P2P bridge. The current i386/x86_64 PCI resource allocation code does not use _CRS returned resource information. No other resource information source is available for slots that are not below a standard P2P bridge so incorrect ranges are being allocated from e820 hole causing the bad result. This patch causes the kernel to use _CRS returned resource info. It is roughly based on a change provided by Matthew Wilcox for the ia64 kernel in 2005. Due to possible buggy BIOS factor and possible yet to be discovered kernel issues the function is disabled by default and can be enabled with pci=use_crs. Signed-off-by: Gary Hade <gary.hade@us.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
5b1ea82f |
|
13-Sep-2007 |
Juha Laiho <Juha.Laiho@iki.fi> |
PCI: i386: Compaq EVO N800c needs PCI bus renumbering Force PCI bus renumbering for Compaq EVO N800c laptop, in order to get the cardbus slot recognised. Signed-off-by: Juha Laiho <Juha.Laiho@iki.fi> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
fb9aa6f1 |
|
11-Oct-2007 |
Thomas Gleixner <tglx@linutronix.de> |
i386: move pci Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
|