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: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NJan Beulich <jbeulich@novell.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

This patch factors out the search for an MMCONFIG region, which was
previously implemented in both mmconfig_32 and mmconfig_64.  No functional
change.
Reviewed-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

No functional change; just tidy up printks and make them more consistent
with the rest of PCI.
Reviewed-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

This changes pci_mmcfg_region from a table to a list, to make it easier
to add and remove MMCONFIG regions for PCI host bridge hotplug.
Reviewed-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

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.
Reviewed-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

This only renames the struct pci_mmcfg_region members; no functional change.
Reviewed-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

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.
Reviewed-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

This factors out the common "bus << 20" expression used when computing the
MMCONFIG address.
Reviewed-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Fix mmconfig detection to not assume a single mmconfig space in the
northbridge, paving the way for AMD fam10h + mcp55 CPUs.  On those, the
MSR has some range, but the mcp55 pci config will have another one.

Also helps the mcp55 + io55 case, where every one will have one range.

If it is mcp55, exclude the range that is used by CPU MSR, in other
words , if the CPU claims busses 0-255, the range in mcp55 is dropped,
because CPU HW will not route those ranges to mcp55 mmconfig to handle
it.
Signed-off-by: NYinghai Lu <yinghai.lu@kernel.org>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

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: NJaswinder Singh Rajput <jaswinderrajput@gmail.com>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

For x86_64, need to free pci_mmcfg_virt, and iounmap some pointers
when MMCONF is not reserved in E820 or acpi _CRS and get rejected.
Signed-off-by: NYinghai Lu <yinghai.lu@sun.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg KH <greg@kroah.com>
Cc: Greg KH <greg@kroah.com>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

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: NMatthew Wilcox <willy@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Thanks to Loic Prylli <loic@myri.com>, who originally proposed
this idea.

Always using legacy configuration mechanism for the legacy config space
and extended mechanism (mmconf) for the extended config space is
a simple and very logical approach. It's supposed to resolve all
known mmconf problems. It still allows per-device quirks (tweaking
dev->cfg_size). It also allows to get rid of mmconf fallback code.
Signed-off-by: NIvan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Some broken devices have been discovered to require %al/%ax/%eax registers
for MMIO config space accesses.  Modify mmconfig.c to use these registers
explicitly (rather than modify the global readb/writeb/etc inlines).

AK: also changed i386 to always use eax
AK: moved change to extended space probing to different patch
AK: reworked with inlines according to Linus' requirements.
AK: improve comments.
Signed-off-by: Ndean gaudet <dean@arctic.org>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Currently, unreachable_devices() compares value of mmconfig and value
of conf1. But it doesn't check the device is reachable or not.
Signed-off-by: NOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: NAndi Kleen <ak@suse.de>

This just cleans up.
Signed-off-by: NOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: NAndi Kleen <ak@suse.de>

MMCONFIG_APER_XXX is unneeded in arch/x86_64/pci/mmconfig.c.
Signed-off-by: NOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: NAndi Kleen <ak@suse.de>

This rejects broken MCFG tables on Asus. When the table
looks bogus just disable mmconfig

Arjan and Andi suggested this.
Signed-off-by: NOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: NAndi Kleen <ak@suse.de>

Current mmconfig has some problems of remapped range.

a) In the case of broken MCFG tables on Asus etc., we need to remap 256M
   range, but currently only remap 1M.

b) The base address always corresponds to bus number 0, but currently we
   are assuming it corresponds to start bus number.

This patch fixes the above problems.

(akpm: Arjan suggests that if the MCFG table is broken we just shouldn't use
it, rather than try to work around things).
Signed-off-by: NOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: NAndi Kleen <ak@suse.de>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>

i386 and x86-64 pci mmconfig code have a lot in common.  So share what's
shareable between the two.
Signed-off-by: NOlivier Galibert <galibert@pobox.com>
Signed-off-by: NAndi Kleen <ak@suse.de>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>

Returning count for tables that are supposed to be unique
was useless and confusing.
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NLen Brown <len.brown@intel.com>

This reverts 4c6e052a commit.

Following Linus' i386 change: revert resource reservation
for mmcfg config now. Will be revisited in .20 hopefully.

Signed-off-by: NDave Jones <davej@redhat.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Cc: gregkh@suse.de
Signed-off-by: NAndi Kleen <ak@suse.de>

On Sat, Sep 09, 2006 at 04:14:29PM +0200, Andi Kleen wrote:
> [patch] Looks reasonable, but probably not for 2.6.18 because this stuff
> is already too fragile and it is probably too risky to do any big changes now
> since not enough testing time is left. Can you please resubmit
> it with proper description and signed-off-by line? I can queue it for .19 then
>
> -Andi

Patch inserts PCI memory mapped config region(s) into the resource map.  This
will allow for the MMCCONFIG regions to be marked as busy in the iomem
address space as well as the regions(s) showing up in /proc/iomem.
Signed-off-by: NAaron Durbin <adurbin@google.com>
Signed-off-by: NAndi Kleen <ak@suse.de>

Needs earlier patch to split type 1 probing from use.

This patch should fix the x86 macs where type 1 PCI config space access
doesn't work, but MCFG does. They also don't have a usable e820 table
so the e820 sanity check failed.

Instead assume now that if type 1 doesn't work then MCFG must work
and don't do the e820 check.
Signed-off-by: NAndi Kleen <ak@suse.de>

First probe if type1/2 accesses work, but then only initialize them at the end.

This is useful for a later patch that needs this information inbetween.
Signed-off-by: NAndi Kleen <ak@suse.de>

Make an mmconfig warning print the bus id with a regular format.
Signed-off-by: NBrice Goglin <brice@myri.com>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>

This reverts commits 11012d41 and
40dd2d20, which allowed us to use the
MMIO accesses for PCI config cycles even without the area being marked
reserved in the e820 memory tables.

Those changes were needed for EFI-environment Intel macs, but broke some
newer Intel 965 boards, so for now it's better to revert to our old
2.6.17 behaviour and at least avoid introducing any new breakage.

Andi Kleen has a set of patches that work with both EFI and the broken
Intel 965 boards, which will be applied once they get wider testing.

Cc: Arjan van de Ven <arjan@infradead.org>
Cc: Edgar Hucek <hostmaster@ed-soft.at>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

As a replacement for the earlier removal of the e820 MCFG check
we blacklist the Intel SDV with the original BIOS bug that
motivated that check. On those machines don't use MMCONFIG.

This also adds a new pci=mmconf parameter to override the blacklist.

Cc: Greg KH <gregkh@suse.de>
Cc: Arjan van de Ven <arjan@infradead.org>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The check for the MCFG table being reserved in the e820 map was originally
added to detect a broken BIOS in a preproduction Intel SDV. However it also
breaks the Apple x86 Macs, which can't supply this properly, but need
a working MCFG. With this patch they wouldn't use the MCFG and not work.

After some discussion I think it's best to remove the heuristic again.
It also failed on some other boxes (although it didn't cause much
problems there because old style port access for PCI config space
still works as fallback), but the preproduction SDVs can just use
pci=nommcfg. Supporting production machines properly is more
important.

Edgar Hucek did all the debugging work.

Cc: Arjan van de Ven <arjan@infradead.org>
Cc: Edgar Hucek <hostmaster@ed-soft.at>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

On 15 Jun 2006 03:45:10 +0200, Andi Kleen wrote:

> Anyways I would say that if the BIOS can't get MCFG right then
> it's likely not been validated on that board and shouldn't be used.

According to Petr Vandrovec:

 ... "What is important (and checked) is address of MMCONFIG reported by MCFG
 table...  Unfortunately code does not bother with printing that address :-(

 "Another problem is that code has hardcoded that MMCONFIG area is 256MB large.
 Unfortunately for the code PCI specification allows any power of two between 2MB
 and 256MB if vendor knows that such amount of busses (from 2 to 128) will be
 sufficient for system.  With notebook it is quite possible that not full 8 bits
 are implemented for MMCONFIG bus number."

So here is a patch.  Unfortunately my system still fails the test because
it doesn't reserve any part of the MMCONFIG area, but this may fix others.

Booted on x86_64, only compiled on i386.  x86_64 still remaps the max area
(256MB) even though only 2MB is checked... but 2.6.16 had no check at all
so it is still better.

PCI: reduce size of x86 MMCONFIG reserved area check

1.  Print the address of the MMCONFIG area when the test for that area
    being reserved fails.

2.  Only check if the first 2MB is reserved, as that is the minimum.
Signed-off-by: NChuck Ebbert <76306.1226@compuserve.com>
Acked-by: NArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Surprising that it still worked at all with this - yes it was
tested.
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Nobody should pass NULL here. Could in theory make it a BUG,
but the NULL pointer oops will do as well.
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Mostly to get better handling when a extended config space
access has to fallback to Type1.

Cc: gregkh@suse.de
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Previously only the first bus would be checked against Type 1.

Why 16? Checking all would need too much memory and we
can assume that systems with more than 16 busses have better than
average quality BIOS.

This is an additional defense against bad MCFG tables.
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This patch introduces a user for the e820_all_mapped function:

There have been several machines that don't have a working MMCONFIG,
often because of a buggy MCFG table in the ACPI bios.  This patch adds a
simple sanity check that detects a whole bunch of these cases, and when
it detects it, linux now boots rather than crash-and-burns.

The accuracy of this detection can in principle be improved if there was
a "is this entire range in e820 with THIS attribute", but no such
function exist and the complexity needed for this is not really worth
it; this simple check already catches most cases anyway.
Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>