19 Dec, 2011
1 commit
-
I noticed that hotplug of one setup does not work with recent change in
pci tree.After checking the bridge conf setup, I noticed that the bridges get
assigned but do not get enabled.The reason is the following commit, while simply ignores bridge
resources when enabling a pci device:| commit bbef98ab0f019f1b0c25c1acdf1683c68933d41b
| Author: Ram Pai
| Date: Sun Nov 6 10:33:10 2011 +0800
|
| PCI: defer enablement of SRIOV BARS
|...
| NOTE: Note, there is subtle change in the pci_enable_device() API. Any
| driver that depends on SRIOV BARS to be enabled in pci_enable_device()
| can fail.Put back bridge resource and ROM resource checking to fix the problem.
That should fix regression like BIOS does not assign correct resource to
bridge.Discussion can be found at:
http://www.spinics.net/lists/linux-pci/msg12874.htmlSigned-off-by: Yinghai Lu
Acked-by: Jesse Barnes
Signed-off-by: Linus Torvalds
15 Dec, 2011
1 commit
-
During test of one IB card with guest VM, found that, msi is not
initialized properly.It turns out __write_msi_msg will do nothing if device current_state is
not PCI_D0. And, that pci device does not have pm_cap in guest VM.There is an error in setting of power state to PCI_D0 in
pci_enable_device(), but error is not returned for this. Following is
code flow:pci_enable_device() --> __pci_enable_device_flags() -->
do_pci_enable_device() --> pci_set_power_state() -->
__pci_start_power_transition()We have following condition inside __pci_start_power_transition():
if (platform_pci_power_manageable(dev)) {
error = platform_pci_set_power_state(dev, state);
if (!error)
pci_update_current_state(dev, state);
} else {
error = -ENODEV;
/* Fall back to PCI_D0 if native PM is not supported */
if (!dev->pm_cap)
dev->current_state = PCI_D0;
}Here, from platform_pci_set_power_state(), acpi_pci_set_power_state() is
getting called and that is failing with ENODEV because of following
condition:if (!handle || ACPI_SUCCESS(acpi_get_handle(handle, "_EJ0",&tmp)))
return -ENODEV;Because of that, pci_update_current_state() is not getting called.
With this patch, if device power state can not be set via
platform_pci_set_power_state and that device does not have native pm
support, then PCI device power state will be set to PCI_D0.-v2: This also reverts 47e9037ac16637cd7f12b8790ea7ce6680e42168, as it's
not needed after this change.Acked-by: "Rafael J. Wysocki"
Signed-off-by: Ajaykumar Hotchandani
Signed-off-by: Yinghai Lu
Signed-off-by: Jesse Barnes
14 Dec, 2011
1 commit
-
Commit 0d52f54e2ef64c189dedc332e680b2eb4a34590a (PCI / ACPI: Make
acpiphp ignore root bridges using PCIe native hotplug) added code
that made the acpiphp driver completely ignore PCIe root complexes
for which the kernel had been granted control of the native PCIe
hotplug feature by the BIOS through _OSC. Unfortunately, however,
this was a mistake, because on some systems there were PCI bridges
supporting PCI (non-PCIe) hotplug under such root complexes and
those bridges should have been handled by acpiphp.For this reason, revert the changes made by the commit mentioned
above and make register_slot() in drivers/pci/hotplug/acpiphp_glue.c
avoid registering hotplug slots for PCIe ports that belong to
root complexes with native PCIe hotplug enabled (which means that
the BIOS has granted the kernel control of this feature for the
given root complex). This is reported to address the original
issue fixed by commit 0d52f54e2ef64c189dedc332e680b2eb4a34590a and
to work on the system where that commit broke things.Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jesse Barnes
06 Dec, 2011
2 commits
-
I get this compile failure on parisc:
drivers/pci/ats.c: In function 'ats_alloc_one':
drivers/pci/ats.c:29: error: implicit declaration of function 'kzalloc'
drivers/pci/ats.c:29: warning: assignment makes pointer from integer without a cast
drivers/pci/ats.c: In function 'ats_free_one':
drivers/pci/ats.c:45: error: implicit declaration of function 'kfree'Because ats.c is missing linux/slab.h as an include. This patch fixes it
Signed-off-by: James Bottomley
Signed-off-by: Jesse Barnes -
All the PCI BARs of a device are enabled when the device is enabled
using pci_enable_device(). This unnecessarily enables SRIOV BARs of the
device.On some platforms, which do not support SRIOV as yet, the
pci_enable_device() fails to enable the device if its SRIOV BARs are not
allocated resources correctly.The following patch fixes the above problem. The SRIOV BARs are now
enabled when IOV capability of the device is enabled in sriov_enable().NOTE: Note, there is subtle change in the pci_enable_device() API. Any
driver that depends on SRIOV BARS to be enabled in pci_enable_device()
can fail.The patch has been touch tested on power and x86 platform.
Tested-by: Michael Wang
Signed-off-by: Ram Pai
Signed-off-by: Jesse Barnes
24 Nov, 2011
1 commit
-
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci:
PCI hotplug: shpchp: don't blindly claim non-AMD 0x7450 device IDs
PCI: pciehp: wait 100 ms after Link Training check
PCI: pciehp: wait 1000 ms before Link Training check
PCI: pciehp: Retrieve link speed after link is trained
PCI: Let PCI_PRI depend on PCI
PCI: Fix compile errors with PCI_ATS and !PCI_IOV
PCI / ACPI: Make acpiphp ignore root bridges using PCIe native hotplug
15 Nov, 2011
1 commit
-
Previously we claimed device ID 0x7450, regardless of the vendor, which is
clearly wrong. Now we'll claim that device ID only for AMD.I suspect this was just a typo in the original code, but it's possible this
change will break shpchp on non-7450 AMD bridges. If so, we'll have to fix
them as we find them.Reference: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638863
Reported-by: Ralf Jung
Cc: Joerg Roedel
Signed-off-by: Bjorn Helgaas
Signed-off-by: Jesse Barnes
12 Nov, 2011
2 commits
-
If the port supports Link speeds greater than 5.0 GT/s, we must wait
for 100 ms after Link training completes before sending configuration
request.Acked-by: Yinghai Lu
Tested-by: Yinghai Lu
Signed-off-by: Kenji Kaneshige
Signed-off-by: Jesse Barnes -
We need to wait for 1000 ms after Data Link Layer Link Active (DLLLA)
bit reads 1b before sending configuration request. Currently pciehp
does this wait after checking Link Training (LT) bit. But we need it
before checking LT bit because LT is still set even after DLLLA bit is
set on some platforms.Acked-by: Yinghai Lu
Tested-by: Yinghai Lu
Signed-off-by: Kenji Kaneshige
Signed-off-by: Jesse Barnes
08 Nov, 2011
1 commit
-
During hot plug, board_added will call pciehp_power_on_slot().
But link speed is updated in pciehp_power_on_slot().We should not update link speed there, because that is too early.
So move the link speed update to pciehp_check_link_status() after making
sure the link has been trained.-v2: fix compile warning that Kenji found.
Signed-off-by: Yinghai Lu
Reviewed-by: Kenji Kaneshige
Tested-by: Kenji Kaneshige
Signed-off-by: Jesse Barnes
07 Nov, 2011
2 commits
-
* 'modsplit-Oct31_2011' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux: (230 commits)
Revert "tracing: Include module.h in define_trace.h"
irq: don't put module.h into irq.h for tracking irqgen modules.
bluetooth: macroize two small inlines to avoid module.h
ip_vs.h: fix implicit use of module_get/module_put from module.h
nf_conntrack.h: fix up fallout from implicit moduleparam.h presence
include: replace linux/module.h with "struct module" wherever possible
include: convert various register fcns to macros to avoid include chaining
crypto.h: remove unused crypto_tfm_alg_modname() inline
uwb.h: fix implicit use of asm/page.h for PAGE_SIZE
pm_runtime.h: explicitly requires notifier.h
linux/dmaengine.h: fix implicit use of bitmap.h and asm/page.h
miscdevice.h: fix up implicit use of lists and types
stop_machine.h: fix implicit use of smp.h for smp_processor_id
of: fix implicit use of errno.h in include/linux/of.h
of_platform.h: delete needless include
acpi: remove module.h include from platform/aclinux.h
miscdevice.h: delete unnecessary inclusion of module.h
device_cgroup.h: delete needless include
net: sch_generic remove redundant use of
net: inet_timewait_sock doesnt need
...Fix up trivial conflicts (other header files, and removal of the ab3550 mfd driver) in
- drivers/media/dvb/frontends/dibx000_common.c
- drivers/media/video/{mt9m111.c,ov6650.c}
- drivers/mfd/ab3550-core.c
- include/linux/dmaengine.h -
* 'trivial' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
scsi: drop unused Kconfig symbol
pci: drop unused Kconfig symbol
stmmac: drop unused Kconfig symbol
x86: drop unused Kconfig symbol
powerpc: drop unused Kconfig symbols
powerpc: 40x: drop unused Kconfig symbol
mips: drop unused Kconfig symbols
openrisc: drop unused Kconfig symbols
arm: at91: drop unused Kconfig symbol
samples: drop unused Kconfig symbol
m32r: drop unused Kconfig symbol
score: drop unused Kconfig symbols
sh: drop unused Kconfig symbol
um: drop unused Kconfig symbol
sparc: drop unused Kconfig symbol
alpha: drop unused Kconfig symbolFix up trivial conflict in drivers/net/ethernet/stmicro/stmmac/Kconfig
as per Michal: the STMMAC_DUAL_MAC config variable is still unused and
should be deleted.
01 Nov, 2011
5 commits
-
These were getting module.h implicitly from device.h but we want
to clean that up, so we fix it here to avoid things like:pci/slot.c: In function ‘pci_hp_create_module_link’:
pci/slot.c:383: error: ‘module_kset’ undeclared (first use in this function)Similarly, rpadlpar_core.c is modular, so add module.h to its includes.
Signed-off-by: Paul Gortmaker
-
They were implicitly getting it from device.h --> module.h but
we want to clean that up. So add the minimal header for these
macros.Signed-off-by: Paul Gortmaker
-
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: Paul Bolle
Reviewed-by: Konrad Rzeszutek Wilk
Signed-off-by: Michal Marek -
This avoids the PCI_PRI question in 'make config' when PCI
is not selected.Reported-by: Geert Uytterhoeven
Signed-off-by: Joerg Roedel
Signed-off-by: Jesse Barnes -
If the kernel has requested control of the PCIe native hotplug
feature for a given root complex, the acpiphp driver should not try
to handle that root complex and it should leave it to pciehp.
Failing to do so causes problems to happen if acpiphp is loaded
before pciehp on such systems.To address this issue make find_root_bridges() ignore PCIe root
complexes with PCIe native hotplug enabled and make add_bridge()
return error code if PCIe native hotplug is enabled for the given
root port. This causes acpiphp to refuse to load if PCIe native
hotplug is enabled for all complexes and to refuse binding to
the root complexes with PCIe native hotplug is enabled.Acked-by: Kenji Kaneshige
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jesse Barnes
29 Oct, 2011
1 commit
-
* 'next-rebase' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci:
PCI: Clean-up MPS debug output
pci: Clamp pcie_set_readrq() when using "performance" settings
PCI: enable MPS "performance" setting to properly handle bridge MPS
PCI: Workaround for Intel MPS errata
PCI: Add support for PASID capability
PCI: Add implementation for PRI capability
PCI: Export ATS functions to modules
PCI: Move ATS implementation into own file
PCI / PM: Remove unnecessary error variable from acpi_dev_run_wake()
PCI hotplug: acpiphp: Prevent deadlock on PCI-to-PCI bridge remove
PCI / PM: Extend PME polling to all PCI devices
PCI quirk: mmc: Always check for lower base frequency quirk for Ricoh 1180:e823
PCI: Make pci_setup_bridge() non-static for use by arch code
x86: constify PCI raw ops structures
PCI: Add quirk for known incorrect MPSS
PCI: Add Solarflare vendor ID and SFC4000 device IDs
28 Oct, 2011
4 commits
-
Clean-up MPS debug output to make it a single line and aligned, thus
making it more readable for a large number of buses and devices in a
single system.Suggested by Benjamin Herrenschmidt
Signed-off-by: Jon Mason
Signed-off-by: Jesse Barnes -
When configuring the PCIe settings for "performance", we allow parents
to have a larger Max Payload Size than children and rely on children
Max Read Request Size to not be larger than their own MPS to avoid
having the host bridge generate responses they can't cope with.However, various drivers in Linux call pci_set_readrq() with arbitrary
values, assuming this to be a simple performance tweak. This breaks
under our "performance" configuration.Fix that by making sure the value programmed by pcie_set_readrq() is
never larger than the configured MPS for that device.Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Jon Mason
Signed-off-by: Jesse Barnes -
Rework the "performance" MPS option to configure the device MPS with the
smaller of the device MPSS or the bridge MPS (which is assumed to be
properly configured at this point to the largest allowable MPS based on
its parent bus).Also, rework the MRRS setting to report an inability to set the MRRS to
a valid setting.Signed-off-by: Jon Mason
Acked-by: Benjamin Herrenschmidt
Signed-off-by: Jesse Barnes -
Intel 5000 and 5100 series memory controllers have a known issue if read
completion coalescing is enabled and the PCI-E Maximum Payload Size is
set to 256B. To work around this issue, disable read completion
coalescing in the memory controller and root complexes. Unfortunately,
it must always be disabled, even if no 256B MPS devices are present, due
to the possibility of one being hotplugged.Links to erratas:
http://www.intel.com/content/dam/doc/specification-update/5000-chipset-memory-controller-hub-specification-update.pdf
http://www.intel.com/content/dam/doc/specification-update/5100-memory-controller-hub-chipset-specification-update.pdfThanks to Jesse Brandeburg and Ben Hutchings for providing insight into
the problem.Tested-and-Reported-by: Avi Kivity
Signed-off-by: Jon Mason
Signed-off-by: Jesse Barnes
26 Oct, 2011
1 commit
-
* 'core-iommu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86, ioapic: Consolidate the explicit EOI code
x86, ioapic: Restore the mask bit correctly in eoi_ioapic_irq()
x86, kdump, ioapic: Reset remote-IRR in clear_IO_APIC
iommu: Rename the DMAR and INTR_REMAP config options
x86, ioapic: Define irq_remap_modify_chip_defaults()
x86, msi, intr-remap: Use the ioapic set affinity routine
iommu: Cleanup ifdefs in detect_intel_iommu()
iommu: No need to set dmar_disabled in check_zero_address()
iommu: Move IOMMU specific code to intel-iommu.c
intr_remap: Call dmar_dev_scope_init() explicitly
x86, x2apic: Enable the bios request for x2apic optout
25 Oct, 2011
1 commit
-
…ci.fixes-3.2' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen
* 'stable/drivers-3.2' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
xenbus: don't rely on xen_initial_domain to detect local xenstore
xenbus: Fix loopback event channel assuming domain 0
xen/pv-on-hvm:kexec: Fix implicit declaration of function 'xen_hvm_domain'
xen/pv-on-hvm kexec: add xs_reset_watches to shutdown watches from old kernel
xen/pv-on-hvm kexec: update xs_wire.h:xsd_sockmsg_type from xen-unstable
xen/pv-on-hvm kexec+kdump: reset PV devices in kexec or crash kernel
xen/pv-on-hvm kexec: rebind virqs to existing eventchannel ports
xen/pv-on-hvm kexec: prevent crash in xenwatch_thread() when stale watch events arrive* 'stable/drivers.bugfixes-3.2' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
xen/pciback: Check if the device is found instead of blindly assuming so.
xen/pciback: Do not dereference psdev during printk when it is NULL.
xen: remove XEN_PLATFORM_PCI config option
xen: XEN_PVHVM depends on PCI
xen/pciback: double lock typo
xen/pciback: use mutex rather than spinlock in vpci backend
xen/pciback: Use mutexes when working with Xenbus state transitions.
xen/pciback: miscellaneous adjustments
xen/pciback: use mutex rather than spinlock in passthrough backend
xen/pciback: use resource_size()* 'stable/pci.fixes-3.2' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
xen/pci: support multi-segment systems
xen-swiotlb: When doing coherent alloc/dealloc check before swizzling the MFNs.
xen/pci: make bus notifier handler return sane values
xen-swiotlb: fix printk and panic args
xen-swiotlb: Fix wrong panic.
xen-swiotlb: Retry up three times to allocate Xen-SWIOTLB
xen-pcifront: Update warning comment to use 'e820_host' option.
15 Oct, 2011
10 commits
-
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: Bjorn Helgaas
Signed-off-by: Joerg Roedel
Signed-off-by: Jesse Barnes -
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: Bjorn Helgaas
Signed-off-by: Joerg Roedel
Signed-off-by: Jesse Barnes -
This patch makes the ATS functions usable for modules.
They will be used by a module implementing some advanced
AMD IOMMU features.Reviewed-by: Bjorn Helgaas
Signed-off-by: Joerg Roedel
Signed-off-by: Jesse Barnes -
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: Bjorn Helgaas
Signed-off-by: Joerg Roedel
Signed-off-by: Jesse Barnes -
The result returned by acpi_dev_run_wake() is always either -EINVAL
or -ENODEV, while obviously it should return 0 on success. The
problem is that the leftover error variable, that's not really used
in the function, is initialized with -ENODEV and then returned
without modification.To fix this issue remove the error variable from acpi_dev_run_wake()
and make the function return 0 on success as appropriate.Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jesse Barnes -
I originally submitted a patch to workaround this by pushing all Ejection
Requests and Device Checks onto the kacpi_hotplug queue.http://marc.info/?l=linux-acpi&m=131678270930105&w=2
The patch is still insufficient in that Bus Checks also need to be added.
Rather than add all events, including non-PCI-hotplug events, to the
hotplug queue, mjg suggested that a better approach would be to modify
the acpiphp driver so only acpiphp events would be added to the
kacpi_hotplug queue.It's a longer patch, but at least we maintain the benefit of having separate
queues in ACPI. This, of course, is still only a workaround the problem.
As Bjorn and mjg pointed out, we have to refactor a lot of this code to do
the right thing but at this point it is a better to have this code working.The acpi core places all events on the kacpi_notify queue. When the acpiphp
driver is loaded and a PCI card with a PCI-to-PCI bridge is removed the
following call sequence occurs:cleanup_p2p_bridge()
-> cleanup_bridge()
-> acpi_remove_notify_handler()
-> acpi_os_wait_events_complete()
-> flush_workqueue(kacpi_notify_wq)which is the queue we are currently executing on and the process will hang.
Move all hotplug acpiphp events onto the kacpi_hotplug workqueue. In
handle_hotplug_event_bridge() and handle_hotplug_event_func() we can simply
push the rest of the work onto the kacpi_hotplug queue and then avoid the
deadlock.Signed-off-by: Prarit Bhargava
Cc: mjg@redhat.com
Cc: bhelgaas@google.com
Cc: linux-acpi@vger.kernel.org
Signed-off-by: Jesse Barnes -
The land of PCI power management is a land of sorrow and ugliness,
especially in the area of signaling events by devices. There are
devices that set their PME Status bits, but don't really bother
to send a PME message or assert PME#. There are hardware vendors
who don't connect PME# lines to the system core logic (they know
who they are). There are PCI Express Root Ports that don't bother
to trigger interrupts when they receive PME messages from the devices
below. There are ACPI BIOSes that forget to provide _PRW methods for
devices capable of signaling wakeup. Finally, there are BIOSes that
do provide _PRW methods for such devices, but then don't bother to
call Notify() for those devices from the corresponding _Lxx/_Exx
GPE-handling methods. In all of these cases the kernel doesn't have
a chance to receive a proper notification that it should wake up a
device, so devices stay in low-power states forever. Worse yet, in
some cases they continuously send PME Messages that are silently
ignored, because the kernel simply doesn't know that it should clear
the device's PME Status bit.This problem was first observed for "parallel" (non-Express) PCI
devices on add-on cards and Matthew Garrett addressed it by adding
code that polls PME Status bits of such devices, if they are enabled
to signal PME, to the kernel. Recently, however, it has turned out
that PCI Express devices are also affected by this issue and that it
is not limited to add-on devices, so it seems necessary to extend
the PME polling to all PCI devices, including PCI Express and planar
ones. Still, it would be wasteful to poll the PME Status bits of
devices that are known to receive proper PME notifications, so make
the kernel (1) poll the PME Status bits of all PCI and PCIe devices
enabled to signal PME and (2) disable the PME Status polling for
devices for which correct PME notifications are received.Tested-by: Sarah Sharp
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jesse Barnes -
Commit 15bed0f2f added a quirk for the e823 Ricoh card reader to lower the
base frequency. However, the quirk first checks to see if the proprietary
MMC controller is disabled, and returns if so. On some devices, such as the
Lenovo X220, the MMC controller is already disabled by firmware it seems,
but the frequency change is still needed so sdhci-pci can talk to the cards.
Since the MMC controller is disabled, the frequency fixup was never being run
on these machines.This moves the e823 check above the MMC controller check so that it always
gets run.This fixes https://bugzilla.redhat.com/show_bug.cgi?id=722509
Signed-off-by: Josh Boyer
Signed-off-by: Jesse Barnes -
The "powernv" platform of the powerpc architecture needs to assign PCI
resources using a specific algorithm to fit some HW constraints of
the IBM "IODA" architecture (related to the ability to create error
handling domains that encompass specific segments of MMIO space).For doing so, it wants to call pci_setup_bridge() from architecture
specific resource management in order to configure bridges after all
resources have been assigned. So make it non-static.Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Jesse Barnes -
Using legacy interrupts and TLPs > 256 bytes on the SFC4000 (all
revisions) may cause interrupt messages to be replayed. In some
systems this results in a non-recoverable MCE. Early boards using the
SFC4000 set the maximum payload size supported (MPSS) to 1024 bytes
and we should override that.There are probably other devices with similar issues, so give this
quirk a generic name.Signed-off-by: Ben Hutchings
Signed-off-by: Jesse Barnes
05 Oct, 2011
1 commit
-
Add the ability to disable PCI-E MPS turning and using the BIOS
configured MPS defaults. Due to the number of issues recently
discovered on some x86 chipsets, make this the default behavior.Also, add the option for peer to peer DMA MPS configuration. Peer to
peer DMA is outside the scope of this patch, but MPS configuration could
prevent it from working by having the MPS on one root port different
than the MPS on another. To work around this, simply make the system
wide MPS the smallest possible value (128B).Signed-off-by: Jon Mason
Acked-by: Benjamin Herrenschmidt
Signed-off-by: Linus Torvalds
21 Sep, 2011
1 commit
-
Change the CONFIG_DMAR to CONFIG_INTEL_IOMMU to be consistent
with the other IOMMU options.Rename the CONFIG_INTR_REMAP to CONFIG_IRQ_REMAP to match the
irq subsystem name.And define the CONFIG_DMAR_TABLE for the common ACPI DMAR
routines shared by both CONFIG_INTEL_IOMMU and CONFIG_IRQ_REMAP.Signed-off-by: Suresh Siddha
Cc: yinghai@kernel.org
Cc: youquan.song@intel.com
Cc: joerg.roedel@amd.com
Cc: tony.luck@intel.com
Cc: dwmw2@infradead.org
Link: http://lkml.kernel.org/r/20110824001456.558630224@sbsiddha-desk.sc.intel.com
Signed-off-by: Ingo Molnar
14 Sep, 2011
1 commit
-
In pcie_find_smpss(), we have the following statement:
if (dev->is_hotplug_bridge && (!list_is_singular(&dev->bus->devices) ||
dev->bus->self->pcie_type != PCI_EXP_TYPE_ROOT_PORT))The problem is that at least on my machine, this gets called for the
root complex (virtual P2P bridge), and dev->bus->self is NULL since
the parent bus for this is not itself anchor to a PCI device.This adds the necessary NULL check.
Signed-off-by: Benjamin Herrenschmidt
Acked-by: Jon Mason
Signed-off-by: Linus Torvalds
10 Sep, 2011
2 commits
-
Modifying the Maximum Read Request Size to 0 (value of 128Bytes) has
massive negative ramifications on some devices. Without knowing which
devices have this issue, do not modify from the default value when
walking the PCI-E bus in pcie_bus_safe mode. Also, make pcie_bus_safe
the default procedure.Tested-by: Sven Schnelle
Tested-by: Simon Kirby
Tested-by: Stephen M. Cameron
Reported-and-tested-by: Eric Dumazet
Reported-and-tested-by: Niels Ole Salscheider
References: https://bugzilla.kernel.org/show_bug.cgi?id=42162
Signed-off-by: Jon Mason
Acked-by: Jesse Barnes
Signed-off-by: Linus Torvalds -
Commit b03e7495a862 ("PCI: Set PCI-E Max Payload Size on fabric")
introduced a potential NULL pointer dereference in calls to
pcie_bus_configure_settings due to attempts to access pci_bus self
variables when the self pointer is NULL.To correct this, verify that the self pointer in pci_bus is non-NULL
before dereferencing it.Reported-by: Stanislaw Gruszka
Signed-off-by: Shyam Iyer
Signed-off-by: Jon Mason
Acked-by: Jesse Barnes
Signed-off-by: Linus Torvalds
27 Aug, 2011
1 commit
-
With Xen changeset 23428 "libxl: Add 'e820_host' option to config file"
the E820 as seen from the host can now be passed into the guest.
This means that a PV guest can now:
- Use the correct PCI I/O gap. Before these patches, Linux guest would
boot up and would tell:
[ 0.000000] Allocating PCI resources starting at 40000000 (gap: 40000000:c0000000)
while in actuality the PCI I/O gap should have been:
[ 0.000000] Allocating PCI resources starting at b0000000 (gap: b0000000:4c000000)- The PV domain with PCI devices was limited to 3GB. It now can be booted
with 4GB, 8GB, or whatever number you want. The PCI devices will now _not_ conflict
with System RAM. Meaning the drivers can load.CC: Jesse Barnes
CC: linux-pci@vger.kernel.org
CC: stable@kernel.org
[v2: Made the string less broken up. Suggested by Joe Perches]
Signed-off-by: Konrad Rzeszutek Wilk
