PCI: unconditionally clear AER uncorr status register during cleanup
The current implementation of pci_cleanup_aer_uncorrect_error_status
only clears either fatal or non-fatal error status bits depending
on the state of the I/O channel. This implementation will then often
leave some bits set after PCI error recovery completes. The uncleared bit
settings will then be falsely reported the next time an AER interrupt is
generated for that hierarchy. An easy way to illustrate this issue is to
use the aer-inject module to simultaneously inject both an uncorrectable
non-fatal and uncorrectable fatal error. One of the errors will not be
cleared.
This patch resolves this issue by unconditionally clearing all bits in
the AER uncorrectable status register. All settings and corrective action
strategies are saved and determined before
pci_cleanup_aer_uncorrect_error_status is called, so this change should not
affect errory handling functionality.
Signed-off-by: Andrew Patterson <andrew.patterson@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Remove 'port_type' field in struct pcie_port_data(), because we can
get port type information from struct pci_dev. With this change, this
patch also does followings:
- Remove struct pcie_port_data because it no longer has any field.
- Remove portdrv private definitions about port type (PCIE_RC_PORT,
PCIE_SW_UPSTREAM_PORT and PCIE_SW_DOWNSTREAM_PORT), and use generic
definitions instead.
Kenji Kaneshige [Wed, 25 Nov 2009 12:04:00 +0000 (21:04 +0900)]
PCI: portdrv: cleanup service irqs initialization
This patch cleans up the service irqs initialization as follows:
- Remove 'irq_mode' field in pcie_port_data and related definitions,
which is not needed because we can get the same information from
'is_msix', 'is_msi' and 'pin' fields in struct pci_dev.
- Change the name of 'vectors' argument of assign_interrupt_mode() to
'irqs' because it holds irq numbers actually. People might confuse
it with CPU vector or MSI/MSI-X vector.
- Change function name assign_interrupt_mode() to init_service_irqs()
becasuse we no longer have 'irq_mode' data structure, and new name
is more straightforward (IMO).
Kenji Kaneshige [Wed, 25 Nov 2009 12:01:28 +0000 (21:01 +0900)]
PCI: portdrv: cleanup pcie_device registration
In the current port bus driver implementation, pcie_device allocation,
initialization and registration are done in separated functions. Doing
those in one function make the code simple and easier to read.
We don't need pcie_port_device_probe() because we can get pci
device/port type using pci_is_pcie() and 'pcie_type' fields in struct
pci_dev. Remove pcie_port_device_probe().
Alex Williamson [Mon, 30 Nov 2009 21:51:44 +0000 (14:51 -0700)]
PCI: Always set prefetchable base/limit upper32 registers
Prior to 1f82de10 we always initialized the upper 32bits of the
prefetchable memory window, regardless of the address range used.
Now we only touch it for a >32bit address, which means the upper32
registers remain whatever the BIOS initialized them too.
It's valid for the BIOS to set the upper32 base/limit to
0xffffffff/0x00000000, which makes us program prefetchable ranges
like 0xffffffffabc00000 - 0x00000000abc00000
Revert the chunk of 1f82de10 that made this conditional so we always
write the upper32 registers and remove now unused pref_mem64 variable.
Signed-off-by: Alex Williamson <alex.williamson@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Shmulik Ravid [Thu, 3 Dec 2009 20:27:51 +0000 (22:27 +0200)]
PCI: read-modify-write the pcie device control register when initiating pcie flr
The pcie_flr routine writes the device control register with the FLR bit
set clearing all other fields for the FLR duration. Among other fields,
the Max_Payload_Size is also cleared which can cause errors if there are
transactions lurking in the HW pipeline. The patch replaces the blank
write with read-modify-write of the control register keeping the other
fields intact.
Bjorn Helgaas [Sat, 14 Nov 2009 00:34:44 +0000 (17:34 -0700)]
x86/PCI: MMCONFIG: remove typeof so we can use a list
This replaces "typeof(pci_mmcfg_config[0])" with the actual type because
I plan to convert pci_mmcfg_config to a list, and then "pci_mmcfg_config[0]"
won't mean anything.
Bjorn Helgaas [Sat, 14 Nov 2009 00:34:39 +0000 (17:34 -0700)]
x86/PCI: MMCONFIG: add virtual address to struct pci_mmcfg_region
The virtual address is only used for x86_64, but it's so much simpler
to manage it as part of the pci_mmcfg_region that I think it's worth
wasting a pointer per MMCONFIG region on x86_32.
Bjorn Helgaas [Sat, 14 Nov 2009 00:34:29 +0000 (17:34 -0700)]
x86/PCI: MMCONFIG: add resource to struct pci_mmcfg_region
This patch adds a resource and corresponding name to the MMCONFIG
structure. This makes allocation simpler (we can allocate the
resource and name at the same time we allocate the pci_mmcfg_region),
and gives us a way to hang onto the resource after inserting it.
This will be needed so we can release and free it when hot-removing
a host bridge.
Bjorn Helgaas [Sat, 14 Nov 2009 00:34:13 +0000 (17:34 -0700)]
x86/PCI: MMCONFIG: use a private structure rather than the ACPI MCFG one
This adds a struct pci_mmcfg_region with a little more information
than the struct acpi_mcfg_allocation used previously. The acpi_mcfg
structure is defined by the spec, so we can't change it.
To begin with, struct pci_mmcfg_region is basically the same as the
ACPI MCFG version, but future patches will add more information.
Bjorn Helgaas [Sat, 14 Nov 2009 00:34:03 +0000 (17:34 -0700)]
x86/PCI: MMCONFIG: reject MMCONFIG apertures at address zero
Since all MMCONFIG regions go through pci_mmconfig_add(), we can test the
address once there. If the caller supplies an address of zero, we never
insert it in the pci_mmcfg_config[] table, so no need to test it elsewhere.
This patch encapsulate pci_mmcfg_config[] updates. All alloc/free is now
done in pci_mmconfig_add() and free_all_mcfg(), so all updates to
pci_mmcfg_config[] and pci_mmcfg_config_num are in those two functions.
This replaces the previous sequence of extend_mmcfg(), fill_one_mmcfg()
with the single pci_mmconfig_add() interface. This interface is currently
static but will eventually be used in the host bridge hot-add path.
Kenji Kaneshige [Fri, 13 Nov 2009 06:14:10 +0000 (15:14 +0900)]
PCI pciehp: fix power fault interrupt storm problem
Enabling power fault detected event notification in current pciehp
might cause power fault interrupt storm on some machines. On those
machines. On those machines, power fault detected bit in the slot
status register was set again immediately when it is cleared in the
interrupt service routine, and next power fault detected interrupt was
notified again. Therefore, disable power fault detected event
notification for now.
This patch also removes unnecessary handling for power fault cleared
event because this event is not supported by PCIe spec.
Kenji Kaneshige [Wed, 11 Nov 2009 05:35:22 +0000 (14:35 +0900)]
PCI: introduce pci_is_pcie()
Introduce pci_is_pcie() which returns true if the specified PCI device
is PCI Express capable, false otherwise.
The purpose of pci_is_pcie() is removing 'is_pcie' flag in the struct
pci_dev, which is not needed because we can check it using 'pcie_cap'
field. To remove 'is_pcie', we need to update user of 'is_pcie' to use
pci_is_pcie() instead first.
Kenji Kaneshige [Wed, 11 Nov 2009 05:34:52 +0000 (14:34 +0900)]
pciehp: use pci_pcie_cap()
Use pci_pcie_cap() instead of pci_find_capability() to get PCIe capability
offset in pciehp driver. This avoids unnecessary search in PCI
configuration space. This patch also removes 'cap_base' field in
struct controller, that was used to hold PCIe capability offset by
pciehp itself.
Kenji Kaneshige [Wed, 11 Nov 2009 05:34:15 +0000 (14:34 +0900)]
PCI hotplug: use pci_pcie_cap()
Use pci_pcie_cap() instead of pci_find_capability() to get PCIe capability
offset in PCI hotplug core. This avoids unnecessary search in PCI
configuration space.
Kenji Kaneshige [Wed, 11 Nov 2009 05:33:30 +0000 (14:33 +0900)]
PCIe ASPM: use pci_pcie_cap()
Use pci_pcie_cap() instead of pci_find_capability() to get PCIe capability
offset in PCIe ASPM driver. This avoids unnecessary search in PCI
configuration space.
Kenji Kaneshige [Wed, 11 Nov 2009 05:32:42 +0000 (14:32 +0900)]
PCIe port bus: use pci_pcie_cap()
Use pci_pcie_cap() instead of pci_find_capability() to get PCIe capability
offset in PCI Express Port Bus driver. This avoids unnecessary serarch
in PCI configuration space.
Kenji Kaneshige [Wed, 11 Nov 2009 05:31:38 +0000 (14:31 +0900)]
PCIe AER: use pci_pcie_cap()
Use pcie_cap() instead of pci_find_capability() to get PCIe capability
offset in PCIe AER driver. This avoids unnecessary search in PCI
configuration space.
Kenji Kaneshige [Wed, 11 Nov 2009 05:30:56 +0000 (14:30 +0900)]
PCI: use pci_pcie_cap() in pci core
Use pcie_cap() instead of pci_find_capability() to get PCIe capability
offset in PCI core code. This avoids unnecessary search in PCI
configuration space.
Kenji Kaneshige [Wed, 11 Nov 2009 05:29:54 +0000 (14:29 +0900)]
PCI: introduce pci_pcie_cap()
Introduce pci_pcie_cap() API that returns saved PCIe capability offset
(currently it is saved in 'pcie_cap' field in the struct PCI dev).
Using pci_pcie_cap() instead of pci_find_capability() avoids
unnecessary search in PCI configuration space.
Linus Torvalds [Mon, 9 Nov 2009 20:04:32 +0000 (12:04 -0800)]
PCI: allow matching of prefetchable resources to non-prefetchable windows
I'm not entirely sure it needs to go into 32, but it's probably the right
thing to do. Another way of explaining the patch is:
- we currently pick the _first_ exactly matching bus resource entry, but
the _last_ inexactly matching one. Normally first/last shouldn't
matter, but bus resource entries aren't actually all created equal: in
a transparent bus, the last resources will be the parent resources,
which we should generally try to avoid unless we have no choice. So
"first matching" is the thing we should always aim for.
- the patch is a bit bigger than it needs to be, because I simplified the
logic at the same time. It used to be a fairly incomprehensible
if ((res->flags & IORESOURCE_PREFETCH) && !(r->flags & IORESOURCE_PREFETCH))
best = r; /* Approximating prefetchable by non-prefetchable */
and technically, all the patch did was to make that complex choice be
even more complex (it basically added a "&& !best" to say that if we
already gound a non-prefetchable window for the prefetchable resource,
then we won't override an earlier one with that later one: remember
"first matching").
- So instead of that complex one with three separate conditionals in one,
I split it up a bit, and am taking advantage of the fact that we
already handled the exact case, so if 'res->flags' has the PREFETCH
bit, then we already know that 'r->flags' will _not_ have it. So the
simplified code drops the redundant test, and does the new '!best' test
separately. It also uses 'continue' as a way to ignore the bus
resource we know doesn't work (ie a prefetchable bus resource is _not_
acceptable for anything but an exact match), so it turns into:
/* We can't insert a non-prefetch resource inside a prefetchable parent .. */
if (r->flags & IORESOURCE_PREFETCH)
continue;
/* .. but we can put a prefetchable resource inside a non-prefetchable one */
if (!best)
best = r;
instead. With the comments, it's now six lines instead of two, but it's
conceptually simpler, and I _could_ have written it as two lines:
if ((res->flags & IORESOURCE_PREFETCH) && !best)
best = r; /* Approximating prefetchable by non-prefetchable */
Isaku Yamahata [Fri, 6 Nov 2009 02:11:43 +0000 (11:11 +0900)]
ia64/xen: compilation fix
This patch fixes the following compilation error introduced by a PCI related
features.
The change set of 5dd1af9f84c79bedd589db89e71ca733f3bf0ebd moves some
xen related definitions from the arch header file
(x86/include/asm/xen/hypervisor.h) to the common header file
(include/xen/xen.h). So ia64/xen also follows it.
In file included from linux-next/include/xen/grant_table.h:41,
from linux-next/drivers/block/xen-blkfront.c:48:
linux-next/arch/ia64/include/asm/xen/hypervisor.h:43: error: nested redefinition of 'enum xen_domain_type'
linux-next/arch/ia64/include/asm/xen/hypervisor.h:43: error: redeclaration of 'enum xen_domain_type'
linux-next/arch/ia64/include/asm/xen/hypervisor.h:44: error: redeclaration of enumerator 'XEN_NATIVE'
linux-next/include/xen/xen.h:5: error: previous definition of 'XEN_NATIVE' was here
linux-next/arch/ia64/include/asm/xen/hypervisor.h:45: error: redeclaration of enumerator 'XEN_PV_DOMAIN'
linux-next/include/xen/xen.h:6: error: previous definition of 'XEN_PV_DOMAIN' was here
linux-next/arch/ia64/include/asm/xen/hypervisor.h:46: error: redeclaration of enumerator 'XEN_HVM_DOMAIN'
linux-next/include/xen/xen.h:7: error: previous definition of 'XEN_HVM_DOMAIN' was here
Bjorn Helgaas [Thu, 5 Nov 2009 17:17:11 +0000 (11:17 -0600)]
x86/PCI: remove 64-bit division
The roundup() caused a build error (undefined reference to `__udivdi3').
We're aligning to power-of-two boundaries, so it's simpler to just use
ALIGN() anyway, which avoids the division.
Kenji Kaneshige [Thu, 5 Nov 2009 03:05:11 +0000 (12:05 +0900)]
PCI: cache PCIe capability offset
There are a lot of codes that searches PCI express capability offset
in the PCI configuration space using pci_find_capability(). Caching it
in the struct pci_dev will reduce unncecessary search. This patch adds
an additional 'pcie_cap' fields into struct pci_dev, which is
initialized at pci device scan time (in set_pcie_port_type()).
Bjorn Helgaas [Mon, 2 Nov 2009 17:45:36 +0000 (10:45 -0700)]
resources: when allocate_resource() fails, leave resource untouched
When "allocate_resource(root, new, size, ...)" fails, we currently
clobber "new". This is inconvenient for the caller, who might care
about the original contents of the resource.
For example, when pci_bus_alloc_resource() fails, the "can't allocate
mem resource %pR" message from pci_assign_resources() currently contains
junk for the resource start/end.
This patch delays the "new" update until we're about to return success.
Bjorn Helgaas [Wed, 4 Nov 2009 17:39:18 +0000 (10:39 -0700)]
x86/PCI: fix bogus host bridge window start/end alignment from _CRS
PCI device BARs are guaranteed to start and end on at least a four-byte
(I/O) or a sixteen-byte (MMIO) boundary because they're aligned on their
size and the low BAR bits are reserved. PCI-to-PCI bridge apertures
have even larger alignment restrictions.
However, some BIOSes (e.g., HP DL360 BIOS P31) report host bridge windows
like "[io 0x0000-0x2cfe]". This is wrong because it excludes the last
port at 0x2cff: it's impossible for a downstream device to claim 0x2cfe
without also claiming 0x2cff. In fact, this BIOS configures a device
behind the bridge to "[io 0x2c00-0x2cff]", so we know the window actually
does include 0x2cff.
This patch rounds the start and end of apertures to the appropriate
boundary. I experimentally determined that Windows contains a similar
workaround; details here:
Bjorn Helgaas [Wed, 4 Nov 2009 17:39:13 +0000 (10:39 -0700)]
x86/PCI: for debuggability, show host bridge windows even when ignoring _CRS
We have occasional problems with PCI resource allocation, and sometimes
they could be avoided by paying attention to what ACPI tells us about
the host bridges. This patch doesn't change the behavior, but it prints
window information that should make debugging easier.
Bjorn Helgaas [Wed, 4 Nov 2009 17:32:52 +0000 (10:32 -0700)]
PCI: replace pr_debug with dev_dbg
Since we have a struct device, we might as well use dev_printk. Note that
both pr_debug() and dev_dbg() are completely compiled out unless DEBUG or
DYNAMIC_DEBUG is defined.
PCI: remove pci_find_slot from PCI_LEGACY config description
Commit 3b073eda has removed pci_find_slot, so there's no point in
mentioning it in the config description as one of the deprecated APIs
there are enabled by PCI_LEGACY and still used by some drivers.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Bjorn Helgaas [Tue, 27 Oct 2009 19:26:47 +0000 (13:26 -0600)]
vsprintf: use %pR, %pr instead of %pRt, %pRf
Jesse accidentally applied v1 [1] of the patchset instead of v2 [2]. This
is the diff between v1 and v2.
The changes in this patch are:
- tidied vsprintf stack buffer to shrink and compute size more
accurately
- use %pR for decoding and %pr for "raw" (with type and flags) instead
of adding %pRt and %pRf
Stefan Assmann [Tue, 27 Oct 2009 07:57:42 +0000 (08:57 +0100)]
PCI: avoid boot interrupt quirk for AMD 813x B1 devices
AMD 813x rev. B1 (like rev. B2) devices generate no interrupts if
quirk_disable_amd_813x_boot_interrupt is executed, add an exception.
http://bugzilla.kernel.org/show_bug.cgi?id=14159
Patch also adds missing cases for DECLARE_PCI_FIXUP_RESUME and
DECLARE_PCI_FIXUP_FINAL calls to quirk_disable_amd_813x_boot_interrupt.
Bjorn Helgaas [Mon, 26 Oct 2009 17:20:47 +0000 (11:20 -0600)]
PCI hotplug: move IOAPIC support from acpiphp to ioapic driver
This patch moves PCI I/O APIC support from acpiphp to a separate driver.
Like pciehp and shpchp, acpiphp handles PCI hotplug, i.e., addition and
removal of PCI adapters. But in addition, acpiphp handles some ACPI
hotplug, such as the addition of new host bridges, and the I/O APIC
support was tangled up with that.
I don't think the I/O APIC support needs to be in acpiphp; PCI I/O APICs
usually appear as a function on a PCI host bridge, and we'll enumerate the
APIC before any of the devices behind the bridge that use it.
As far as I know, nobody actually uses I/O APIC hotplug. It depends on
acpi_register_ioapic(), which is only implemented for ia64, and I don't
think any vendors have supported I/O chassis hotplug yet.
Andrew Patterson [Mon, 12 Oct 2009 19:14:00 +0000 (13:14 -0600)]
PCI: add pci_get_domain_bus_and_slot function
Added the pci_get_domain_and_slot_function which is analogous to
pci_get_bus_and_slot. It returns a pci_dev given a domain (segment) number,
bus number, and devnr. Like pci_get_bus_and_slot,
pci_get_domain_bus_and_slot holds a reference to the returned pci_dev.
Converted pci_get_bus_and_slot to a wrapper that calls
pci_get_domain_bus_and_slot with the domain hard-coded to 0.
This routine was patterned off code suggested by Bjorn Helgaas.
Gabe Black [Tue, 6 Oct 2009 15:45:19 +0000 (10:45 -0500)]
PCI: populate subsystem vendor and device IDs for PCI bridges
Change to populate the subsystem vendor and subsytem device IDs for
PCI-PCI bridges that implement the PCI Subsystem Vendor ID capability.
Previously bridges left subsystem vendor IDs unpopulated.
Signed-off-by: Gabe Black <gabe.black@ni.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Matt Domsch [Mon, 2 Nov 2009 17:51:24 +0000 (11:51 -0600)]
PCI: PCIe AER: honor ACPI HEST FIRMWARE FIRST mode
Feedback from Hidetoshi Seto and Kenji Kaneshige incorporated. This
correctly handles PCI-X bridges, PCIe root ports and endpoints, and
prints debug messages when invalid/reserved types are found in the
HEST. PCI devices not in domain/segment 0 are not represented in
HEST, thus will be ignored.
Today, the PCIe Advanced Error Reporting (AER) driver attaches itself
to every PCIe root port for which BIOS reports it should, via ACPI
_OSC.
However, _OSC alone is insufficient for newer BIOSes. Part of ACPI
4.0 is the new APEI (ACPI Platform Error Interfaces) which is a way
for OS and BIOS to handshake over which errors for which components
each will handle. One table in ACPI 4.0 is the Hardware Error Source
Table (HEST), where BIOS can define that errors for certain PCIe
devices (or all devices), should be handled by BIOS ("Firmware First
mode"), rather than be handled by the OS.
Dell PowerEdge 11G server BIOS defines Firmware First mode in HEST, so
that it may manage such errors, log them to the System Event Log, and
possibly take other actions. The aer driver should honor this, and
not attach itself to devices noted as such.
Furthermore, Kenji Kaneshige reminded us to disallow changing the AER
registers when respecting Firmware First mode. Platform firmware is
expected to manage these, and if changes to them are allowed, it could
break that firmware's behavior.
The HEST parsing code may be replaced in the future by a more
feature-rich implementation. This patch provides the minimum needed
to prevent breakage until that implementation is available.
Kenji Kaneshige [Mon, 5 Oct 2009 08:42:59 +0000 (17:42 +0900)]
PCI: pciehp: return error on read/write failure
Current pciehp returns successfully on read/write failure with dummy
state values. It should return error instead.
With this patch, pciehp no longer uses hotplug_slot_info data
structure. So this also removes hotplug_slot_info related code. But
note that it still allocates hotplug_slot_info because it is required
by pci hotplug core.
Kenji Kaneshige [Mon, 5 Oct 2009 08:41:37 +0000 (17:41 +0900)]
PCI: pciehp: create files only for existing capabilities
Current pciehp driver creates 'attention' and 'latch' files even if
the controller doesn't support them. In this case, the contents of
those files are meaningless and unpredictable. Those files should be
created only if the controller has the corresponding capabilities.
Kenji Kaneshige [Mon, 5 Oct 2009 08:40:02 +0000 (17:40 +0900)]
PCI: pciehp: disable DLL state changed event notification
Current pciehp doesn't handle Data Link Layer State Changed Event
notification. So it needs to be disabled at initialization time,
otherwise other event notifications are not generated.
When probing for ROM BAR size, we should not change bits 1:10 in this
BAR, because these bits are marked as "reserved for future use" in PCI
spec, so changing them might have side effects.
No such issue for I/O or memory, as there is an implementation note in
PCI spec which explicitly allows writing 0xfffffffff there.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Allen Kay [Wed, 7 Oct 2009 17:27:51 +0000 (10:27 -0700)]
PCI: add xen dom0 checking before ACS initialization
This patch is predicated on Jeremy's patch in include/xen/xen.h. It'll
prevent ACS init unless the platform has both an IOMMU and we're running
as dom0.
Signed-off-by: Allen Kay <allen.m.kay@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Allen Kay [Wed, 7 Oct 2009 17:27:17 +0000 (10:27 -0700)]
PCI: acs p2p upsteram forwarding enabling
Note: dom0 checking in v4 has been separated out into 2/2.
This patch enables P2P upstream forwarding in ACS capable PCIe switches.
It solves two potential problems in virtualization environment where a PCIe
device is assigned to a guest domain using a HW iommu such as VT-d:
1) Unintentional failure caused by guest physical address programmed
into the device's DMA that happens to match the memory address range
of other downstream ports in the same PCIe switch. This causes the PCI
transaction to go to the matching downstream port instead of go to the
root complex to get translated by VT-d as it should be.
2) Malicious guest software intentionally attacks another downstream
PCIe device by programming the DMA address into the assigned device
that matches memory address range of the downstream PCIe port.
We are in process of implementing device filtering software in KVM/XEN
management software to allow device assignment of PCIe devices behind a PCIe
switch only if it has ACS capability and with the P2P upstream forwarding bits
enabled. This patch is intended to work for both KVM and Xen environments.
Signed-off-by: Allen Kay <allen.m.kay@intel.com> Reviewed-by: Mathew Wilcox <willy@linux.intel.com> Reviewed-by: Chris Wright <chris@sous-sol.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Bjorn Helgaas [Fri, 23 Oct 2009 21:20:33 +0000 (15:20 -0600)]
x86/PCI: allow MMCONFIG above 4GB
The current whitelist requires a kernel change for every machine that has
MMCONFIG regions above 4GB, even if BIOS provides a correct MCFG table.
This patch expands the whitelist to include machines with a rev 1 or newer
MCFG table and a DMI_BIOS_DATE of 2010 or later. That way, we only need
kernel changes for new machines that provide incorrect MCFG tables.
Suresh Siddha [Mon, 26 Oct 2009 21:21:32 +0000 (13:21 -0800)]
x86/PCI/PAT: return EINVAL for pci mmap WC request for !pat_enabled
Thomas Schlichter reported:
> X.org uses libpciaccess which tries to mmap with write combining enabled via
> /sys/bus/pci/devices/*/resource0_wc. Currently, when PAT is not enabled, the
> kernel does fall back to uncached mmap. Then libpciaccess thinks it succeeded
> mapping with write combining enabled and does not set up suited MTRR entries.
> ;-(
Instead of silently mapping pci mmap region as UC minus in the case
of !pat_enabled and wc request, we can return error. Eric Anholt mentioned
that caller (like X) typically follows up with UC minus pci mmap request and
if there is a free mtrr slot, caller will manage adding WC mtrr.
Jesse Barnes says:
> Older versions of libpciaccess will behave better if we do it that way
> (iirc it only allocates an MTRR if the resource_wc file doesn't exist or
> fails to get mapped).
Reported-by: Thomas Schlichter <thomas.schlichter@web.de> Signed-off-by: Thomas Schlichter <thomas.schlichter@web.de> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Acked-by: Eric Anholt <eric@anholt.net> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Bjorn Helgaas [Tue, 6 Oct 2009 21:33:39 +0000 (15:33 -0600)]
vsprintf: add %pRt, %pRf to print struct resource details
This adds support for printing struct resource type and flag information.
For example, "%pRt" looks like "[mem 0x80080000000-0x8008001ffff 64bit pref]",
and "%pRf" looks like "[mem 0xff5e2000-0xff5e2007 pref flags 0x1]".
Bjorn Helgaas [Tue, 6 Oct 2009 21:33:34 +0000 (15:33 -0600)]
vsprintf: add %pR support for IRQ and DMA resources
Print addresses (IO port numbers and memory addresses) in hex, but print
others (IRQs and DMA channels) in decimal. Only print the end if it's
different from the start.
Bjorn Helgaas [Tue, 6 Oct 2009 21:33:29 +0000 (15:33 -0600)]
vsprintf: fix io/mem resource width
The leading "0x" consumes field width, so leave space for it in addition to
the 4 or 8 hex digits. This means we'll print "0x0000-0x01df" rather than
"0x00-0x1df", for example.
Matthew Garrett [Mon, 26 Oct 2009 17:18:22 +0000 (13:18 -0400)]
PCI hotplug: acpiphp should be linked after vendor drivers
As a followup to 71a082efc9fdc12068a3cee6cebb1330b00ebeee, it's conceivable
that some vendors may expose PCI hotplug functionality through both vendor
mechanisms and ACPI. The native mechanism will generally be a superset of
any functionality provided via ACPI, so the acpiphp driver should always
be initialised after any others. Change the link order such that acpiphp
will not be initialised until any other statically linked drivers have had
an opportunity to claim the hardware.
Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Dave Jones [Wed, 14 Oct 2009 20:31:39 +0000 (16:31 -0400)]
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>
projects / karo-tx-linux.git / log