This makes PCI resource management messages more consistent and adds a few
new messages to aid debugging.

Whenever we assign resources to a device, update a BAR, or change a
bridge aperture, it's worth noting it.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

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

[1] http://lkml.org/lkml/2009/10/6/491
[2] http://lkml.org/lkml/2009/10/13/441Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

This uses %pRt to print additional resource information (type, size,
prefetchability, etc.) consistently.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

This reverts commit 308cf8e1.  This
patch had trouble with transparent bridges, among other things.  A more
readable and correct version should land in 2.6.33.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Found one system:
[   71.120590] pci 0000:40:05.0: scanning behind bridge, config 4f4a40, pass 0
[   71.138283] PCI: Scanning bus 0000:4a
[   71.140341] pci 0000:4a:00.0: found [15b3:6278] class 000c06 header type 00
[   71.157173] pci 0000:4a:00.0: reg 10 64bit mmio: [0x000000-0x0fffff]
[   71.161697] pci 0000:4a:00.0: reg 18 64bit mmio pref: [0x000000-0x7fffff]
[   71.179403] pci 0000:4a:00.0: reg 20 64bit mmio pref: [0x000000-0xfffffff]
[   71.185366] pci 0000:4a:00.0: calling quirk_resource_alignment+0x0/0x1dd
[   71.200846] pci 0000:4a:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
[   71.219623] PCI: Fixups for bus 0000:4a
[   71.222194] pci 0000:40:05.0: bridge 32bit mmio: [0xcf000000-0xcf0fffff]
[   71.238662] pci 0000:40:05.0: bridge 64bit mmio pref: [0xcd800000-0xcdffffff]
[   71.255793] PCI: Bus scan for 0000:4a returning with max=4a

Device needs a big pref mmio, but BIOS doesn't allocate mmio to it aside
from a small MMIO range.  Later, the kernel will not allocate resources to
that to the device:
[   99.574030] pci 0000:4a:00.0: BAR 4: can't allocate mem resource [0xd0000000-0xcdffffff]
[   99.580102] pci 0000:4a:00.0: BAR 2: got res [0xcd800000-0xcdffffff] bus [0xcd800000-0xcdffffff] flags 0x12120c
[   99.602307] pci 0000:4a:00.0: BAR 2: moved to bus [0xcd800000-0xcdffffff] flags 0x12120c
[   99.615991] pci 0000:4a:00.0: BAR 0: got res [0xcf000000-0xcf0fffff] bus [0xcf000000-0xcf0fffff] flags 0x120204
[   99.634499] pci 0000:4a:00.0: BAR 0: moved to bus [0xcf000000-0xcf0fffff] flags 0x120204
[   99.654318] pci 0000:40:05.0: PCI bridge, secondary bus 0000:4a
[   99.658766] pci 0000:40:05.0:   IO window: disabled
[   99.675478] pci 0000:40:05.0:   MEM window: 0xcf000000-0xcf0fffff
[   99.681663] pci 0000:40:05.0:   PREFETCH window: 0x000000cd800000-0x000000cdffffff

So try to get a big range in the pci bridge if there is no child using
that range.  With the patch we get:
[   99.104525] pci 0000:4a:00.0: BAR 4: got res [0xfc080000000-0xfc08fffffff] bus [0xfc080000000-0xfc08fffffff] flags 0x12120c
[   99.123624] pci 0000:4a:00.0: BAR 4: moved to bus [0xfc080000000-0xfc08fffffff] flags 0x12120c
[   99.131977] pci 0000:4a:00.0: BAR 2: got res [0xfc090000000-0xfc0907fffff] bus [0xfc090000000-0xfc0907fffff] flags 0x12120c
[   99.149788] pci 0000:4a:00.0: BAR 2: moved to bus [0xfc090000000-0xfc0907fffff] flags 0x12120c
[   99.169248] pci 0000:4a:00.0: BAR 0: got res [0xc0200000-0xc02fffff] bus [0xc0200000-0xc02fffff] flags 0x120204
[   99.189508] pci 0000:4a:00.0: BAR 0: moved to bus [0xc0200000-0xc02fffff] flags 0x120204
[   99.206402] pci 0000:40:05.0: PCI bridge, secondary bus 0000:4a
[   99.210637] pci 0000:40:05.0:   IO window: disabled
[   99.224856] pci 0000:40:05.0:   MEM window: 0xc0200000-0xc03fffff
[   99.230019] pci 0000:40:05.0:   PREFETCH window: 0x000fc080000000-0x000fc097ffffff
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

In general a BIOS may goof or we may hotplug in a hotplug controller.
In either case the kernel needs to reserve resources for plugging
in more devices in the future instead of creating a minimal resource
assignment.

We already do this for cardbus bridges I am just adding a variant
for pcie bridges.

v2: Make testing for pcie hotplug bridges based on a flag.

    So far we only set the flag for pcie but a header_quirk
    could easily be added for the non-standard pci hotplug
    bridges.
Signed-off-by: NEric W. Biederman <ebiederm@aristanetworks.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

An SR-IOV capable device includes an SR-IOV PCIe capability which
describes the Virtual Function (VF) BAR requirements.  A typical SR-IOV
device can support multiple VFs whose BARs must be in a contiguous region,
effectively an array of VF BARs.  The BAR reports the size requirement
for a single VF.  We calculate the full range needed by simply multiplying
the VF BAR size with the number of possible VFs and create a resource
spanning the full range.

This all seems sane enough except it artificially inflates the alignment
requirement for the VF BAR.  The VF BAR need only be aligned to the size
of a single BAR not the contiguous range of VF BARs.  This can cause us
to fail to allocate resources for the BAR despite the fact that we
actually have enough space.

This patch adds a thin PCI specific layer over the generic
resource_alignment() function which is aware of the special nature of
VF BARs and does sorting and allocation based on the smaller alignment
requirement.

I recognize that while resource_alignment is generic, it's basically a
PCI helper.  An alternative to this patch is to add PCI VF BAR specific
information to struct resource.  I opted for the extra layer rather than
adding such PCI specific information to struct resource.  This does
have the slight downside that we don't cache the BAR size and re-read
for each alignment query (happens a small handful of times during boot
for each VF BAR).
Signed-off-by: NChris Wright <chrisw@sous-sol.org>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matthew Wilcox <matthew@wil.cx>
Cc: Yu Zhao <yu.zhao@intel.com>
Cc: stable@kernel.org
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

We could run out of space under under 4g, but devices under transparent
bridges can use 64bit resources, so keep trying on the parent bus until
we hit a non-transparent bridge.

Impact: better support for assigning unassigned resources
Reviewed-by: NIvan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

We should not assign 64bit ranges to PCI devices that only take 32bit
prefetchable addresses.

Try to set IORESOURCE_MEM_64 in 64bit resource of pci_device/pci_bridge
and make the bus resource only have that bit set when all devices under
it support 64bit prefetchable memory.  Use that flag to allocate
resources from that range.
Reported-by: NYannick <yannick.roehlly@free.fr>
Reviewed-by: NIvan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Remove outputs for 0 sized resources and indicate prefetchability.
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

This patch sets up disabled bridges even if buses have already been
added.

pci_assign_unassigned_resources is called after buses are added.
pci_assign_unassigned_resources calls pci_bus_assign_resources.
pci_bus_assign_resources calls pci_setup_bridge to configure BARs of
bridges.

Currently pci_setup_bridge returns immediately if the bus have already
been added. So pci_assign_unassigned_resources can't configure BARs of
bridges that were added in a disabled state; this patch fixes the issue.

On logical hot-add, we need to prevent the kernel from re-initializing
bridges that have already been initialized. To achieve this,
pci_setup_bridge returns immediately if the bridge have already been
enabled.

We don't need to check whether the specified bus is a root bus or not.
pci_setup_bridge is not called on a root bus, because a root bus does
not have a bridge.

The patch adds a new helper function, pci_is_enabled. I made the
function name similar to pci_is_managed. The codes which use
enable_cnt directly are changed to use pci_is_enabled.
Acked-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NYuji Shimada <shimada-yxb@necst.nec.co.jp>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

In preparation for PCI core hotplug, we need to ensure that we do
not attempt to re-initialize bridges that have already been initialized.

We only need to worry about non-root buses, since we will not allow
root bus removal.
Reported-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

drivers/pci/hotplug/fakephp.c: In function 'pci_rescan_bus':
drivers/pci/hotplug/fakephp.c:271: warning: passing argument 1 of 'pci_bus_assign_resources' discards qualifiers from pointer target type
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Since pci_bus has a struct device, use dev_printk directly instead
of faking it by hand.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Change PCI bus resource messages so they have a bit more context
and look like the rest of PCI, e.g.,

    - bus: 00 index 0 io port: [0x00-0xffff]
    - bus: 00 index 1 mmio: [0x000000-0xffffffff]
    + pci 0000:00: bus resource 0 io : [0x00-0xffff]
    + pci 0000:00: bus resource 1 mem: [0x000000-0xffffffff]

This also changes them from KERN_INFO to KERN_DEBUG.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

This is a cleanup that replaces the resource calculation formula with
resource_size().
Signed-off-by: NYu Zhao <yu.zhao@intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

This converts things in drivers/pci to use %pR to printout the
content of a struct resource instead of hand-casted %llx or
other variants.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

There's no good reason why a resource_size_t shouldn't just be a
physical address, so simply redefine it in terms of phys_addr_t.
Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Again, the cleaned up code introduced some resource warnings:
drivers/pci/setup-bus.c: In function 'pci_bus_dump_res':
drivers/pci/setup-bus.c:542: warning: format '%llx' expects type 'long long unsigned int', but argument 5 has type 'resource_size_t'
drivers/pci/setup-bus.c:542: warning: format '%llx' expects type 'long long unsigned int', but argument 6 has type 'resource_size_t'

Fix those up too.
Signed-off-by: NJohann Felix Soden <johfel@users.sourceforge.net>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Commit 88452565 ("PCI: clean up resource
alignment management") changed the resource handling to mark how a
resource was aligned on a per-resource basis.

Thus, instead of looking at the resource number to determine whether it
was a bridge resource or a regular resource (they have different
alignment rules), we should just ask the resource for its alignment
directly.

The reason this broke only cardbus resources was that for the other
types of resources, the old way of deciding alignment actually still
happened to work.  But CardBus bridge resources had been changed by
commit 934b7024 ("Fix cardbus resource
allocation") to look more like regular resources than PCI bridge
resources from an alignment handling standpoint.
Reported-and-tested-by: NAndrew Morton <akpm@linux-foundation.org>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Convert printks to use dev_printk().

I converted pr_debug() to dev_dbg().  Both use KERN_DEBUG and are enabled
only when DEBUG is defined.

I converted printk(KERN_DEBUG) to dev_printk(KERN_DEBUG), not to dev_dbg(),
because dev_dbg() is only enabled when DEBUG is defined.

I converted DBG(KERN_INFO) (only in setup-bus.c) to dev_info().  The DBG()
name makes it sound like debug, but it's been enabled forever, so dev_info()
preserves the previous behavior.

I tried to make the resource assignment formats more consistent, e.g.,
  "BAR %d: got res [%#llx-%#llx] bus [%#llx-%#llx] flags %#lx\n"
instead of sometimes using "start-end" and sometimes using "size@start".
I'm not attached to one or the other; I'd just like them consistent.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Signed-off-by: NIngo Molnar <mingo@elte.hu>

Commit 88452565 ("PCI: clean up resource
alignment management") didn't set the alignment information for the
cardbus window resources, causing their subsequent allocations to fail
miserably with a message like

  yenta_cardbus 0000:15:00.0: device not available because of BAR 7 [100:1ff] collisions
  yenta_cardbus: probe of 0000:15:00.0 failed with error -16

or similar.

This fixes it and clarifies the code a bit too (we used to have to use
the insane PCI bridge alignment logic that put the alignment in the
"start" field, this makes it use the slightly easier-to-understand
size-based alignment, and allows us to set the resource start to zero
until it gets allocated).
Reported-and-tested-by: NJeff Chua <jeff.chua.linux@gmail.com>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

WARNING: drivers/pci/built-in.o(.text+0x28ee9): Section mismatch in reference from the function pci_bus_assign_resources() to the function .devinit.text:pci_setup_bridge()
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

WARNING: drivers/pci/built-in.o(.text+0x28e1f): Section mismatch in reference from the function pci_bus_size_bridges() to the function .devinit.text:pci_bus_size_cardbus()
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Done per Linus' request and suggestions. Linus has explained that
better than I'll be able to explain:

On Thu, Mar 27, 2008 at 10:12:10AM -0700, Linus Torvalds wrote:
> Actually, before we go any further, there might be a less intrusive
> alternative: add just a couple of flags to the resource flags field (we
> still have something like 8 unused bits on 32-bit), and use those to
> implement a generic "resource_alignment()" routine.
>
> Two flags would do it:
>
>  - IORESOURCE_SIZEALIGN: size indicates alignment (regular PCI device
>    resources)
>
>  - IORESOURCE_STARTALIGN: start field is alignment (PCI bus resources
>    during probing)
>
> and then the case of both flags zero (or both bits set) would actually be
> "invalid", and we would also clear the IORESOURCE_STARTALIGN flag when we
> actually allocate the resource (so that we don't use the "start" field as
> alignment incorrectly when it no longer indicates alignment).
>
> That wouldn't be totally generic, but it would have the nice property of
> automatically at least add sanity checking for that whole "res->start has
> the odd meaning of 'alignment' during probing" and remove the need for a
> new field, and it would allow us to have a generic "resource_alignment()"
> routine that just gets a resource pointer.

Besides, I removed IORESOURCE_BUS_HAS_VGA flag which was unused for ages.
Signed-off-by: NIvan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Gary Hade <garyhade@us.ibm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This reverts commit 8fa5913d, which
caused various interesting problems for people, including wrong resource
allocations.  See for example bugzilla entry "2.6.25-rc2: ohci1394
problem (MMIO broken)" at

	http://bugzilla.kernel.org/show_bug.cgi?id=10080

And Gary Hade says:

 "The same change had also exposed an issue reported by Paul Martin that
  has been causing an Oops while hotplugging ThinkPads to a ThinkPad
  Dock II.  See

	http://lkml.org/lkml/2008/2/19/405
	http://bugzilla.kernel.org/show_bug.cgi?id=9961

  I have a fix for the ThinkPad docking Oops but if the issue being
  discussed here is caused by the transparent bridge sizing removal
  change I totally agree that it should be reverted."

  The transparent bridge sizing removal change was motivated by
  insufficient PCI memory resource for a transparent bridge window that
  was being created as a result of expansion ROM(s) being included in
  the transparent bridge sizing calculations.

  A later "PCI: Remove default PCI expansion ROM memory allocation"
  change ( re: http://lkml.org/lkml/2007/12/11/361 ) removes the
  expansion ROM(s) from the transparent bridge sizing calculations which
  actually resolves the original issue in a different manner.  So, even
  if the "PCI: remove transparent bridge sizing" is not problematic it
  is no longer needed anyway."
Identified-by: NIvan Kokshaysky <ink@jurassic.park.msu.ru>
Tested-by: NThomas Meyer <thomas@m3y3r.de>
Acked-by: NGary Hade <garyhade@us.ibm.com>
Acked-by: NIngo Molnar <mingo@elte.hu>
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Use upper_32_bits(): no code changes, one less ifdef.
Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The following warnings were issued during build of
drivers/pci with an allyesconfig build:
WARNING: o-x86_64/drivers/pci/built-in.o(.text+0xdaf): Section mismatch in reference from the function pci_add_new_bus() to the function .devinit.text:pci_alloc_child_bus()
WARNING: o-x86_64/drivers/pci/built-in.o(.text+0x15e2): Section mismatch in reference from the function pci_scan_single_device() to the function .devinit.text:pci_scan_device()
WARNING: o-x86_64/drivers/pci/built-in.o(.text+0x1b0c5): Section mismatch in reference from the function pci_bus_assign_resources() to the function .devinit.text:pci_setup_bridge()
WARNING: o-x86_64/drivers/pci/built-in.o(.text+0x1b32d): Section mismatch in reference from the function pci_bus_size_bridges() to the function .devinit.text:pci_bus_size_cardbus()

Investigating each case closer it looked like all
referred functions are only used in the init phase
or during hotplug.
So to avoid wasting too much memory in the non-hotplug
case the simpler fix was to allow the fuctions to
use code/data from the __devinit sections.
This was done in all four case by adding the __ref
annotation.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Cc: Adrian Bunk <bunk@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The current pci_assign_unassigned_resources() code doesn't work properly
on 32 bits platforms with 64 bits resources. The main reason is the use
of unsigned long in various places instead of resource_size_t.

This is a pre-requisite for making powerpc use the generic code instead of
its own half-useful implementation.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Remove transparent bridge sizing.

Due to code in pci_read_bridge_bases() [drivers/pci/probe.c] the child
bus of a transparent bridge already has access to the parent bus
resources so transparent bridge sizing appears unnecessary.  The bridge
sizing includes alignment and granularity adjustments that can cause
significantly more memory to be reserved from the parant bus than
required by devices on the child bus and allotted by _CRS.
Signed-off-by: NGary Hade <gary.hade@us.ibm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

ROUND_UP macro cleanup, use ALIGN where ever appropriate
Signed-off-by: NMilind Arun Choudhary <milindchoudhary@gmail.com>
Acked-by: NScott Murray <scottm@somanetworks.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Functions marked __devinit will be removed after kernel init.  But being
exported they are potentially called by a module much later.

So the safer choice seems to be to keep the function even in the non
CONFIG_HOTPLUG case.

This silence the follwoing section mismatch warnings:
WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_add_device from __ksymtab_gpl between '__ksymtab_pci_bus_add_device' (at offset 0x20) and '__ksymtab_pci_walk_bus'
WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_create_bus from __ksymtab_gpl between '__ksymtab_pci_create_bus' (at offset 0x40) and '__ksymtab_pci_stop_bus_device'
WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_max_busnr from __ksymtab_gpl between '__ksymtab_pci_bus_max_busnr' (at offset 0xc0) and '__ksymtab_pci_assign_resource_fixed'
WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_claim_resource from __ksymtab_gpl between '__ksymtab_pci_claim_resource' (at offset 0xe0) and '__ksymtab_pcie_port_bus_type'
WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_add_devices from __ksymtab between '__ksymtab_pci_bus_add_devices' (at offset 0x70) and '__ksymtab_pci_bus_alloc_resource'
WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_scan_bus_parented from __ksymtab between '__ksymtab_pci_scan_bus_parented' (at offset 0x90) and '__ksymtab_pci_root_buses'
WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_assign_resources from __ksymtab between '__ksymtab_pci_bus_assign_resources' (at offset 0x4d0) and '__ksymtab_pci_bus_size_bridges'
WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_size_bridges from __ksymtab between '__ksymtab_pci_bus_size_bridges' (at offset 0x4e0) and '__ksymtab_pci_setup_cardbus'
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

CARDBUS_MEM_SIZE was increased to 64MB on 2.6.20-rc2, but larger size might
result in allocation failure for the reserving itself on some platforms
(for example typical 32bit MIPS).  Make it (and CARDBUS_IO_SIZE too)
customizable by "pci=" option for such platforms.
Signed-off-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: Daniel Ritz <daniel.ritz@gmx.ch>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Linus sayeth:

Google knows everything, and finds, on MS own site no less:

  "Windows 2000 default resources:

   One 4K memory window

   One 2 MB memory window

   Two 256-byte I/O windows"

which is clearly utterly bogus and insufficient. But Microsoft apparently
realized this, and:

  "Windows XP default resources:

   Because one memory window of 4K and one window of 2 MB are not
   sufficient for CardBus controllers in many configurations, Windows XP
   allocates larger memory windows to CardBus controllers where possible.
   However, resource windows are static (that is, the operating system
   does not dynamically allocate larger memory windows if new devices
   appear.) Under Windows XP, CardBus controllers will be assigned the
   following resources:

   One 4K memory window, as in Windows 2000

   64 MB memory, if that amount of memory is available. If 64 MB is not
   available the controller will receive 32 MB; if 32 MB is not available,
   the controller will receive 16 MB; if 16 MB is not available, the
   bridge will receive 8 MB; and so on down to a minimum assignment of 1
   MB in configurations where memory is too constrained for the operating
   system to provide a larger window.

   Two 256-byte I/O windows"

So I think we have our answer. Windows uses one 4k window, and one 64MB
window. And they are no more dynamic than we are (we _could_ try to do it
dynamically, but let's face it, it's fairly painful to dynamically expand
PCI bus resources - you may need to reprogram everything up to the root,
so it would be absolutely crazy to do that unless you have some serious
masochistic tendencies).

So let's just increase our default value to 64M too.

Cc: Markus Rechberger <mrechberger@gmail.com>
Cc: Daniel Ritz <daniel.ritz@gmx.ch>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Roland Dreier wrote:
> The change "PCI: assign ioapic resource at hotplug" (commit
> 23186279 in Linus's tree) makes
> networking stop working on my system (SuperMicro H8QC8 with four
> dual-core Opteron 885 CPUs).  In particular, the on-board NIC stops
> working, probably because it gets assigned the wrong IRQ (225 in the
> non-working case, 217 in the working case)
>
> With that patch applied, e1000 doesn't work.  Reverting just that
> patch (shown below) from Linus's latest tree fixes things for me.
>

The cause of this problem might be an wrong assumption that the 'start'
member of resource structure for ioapic device has non-zero value if the
resources are assigned by firmware.  The 'start' member of ioapic device
seems not to be set even though the resources were actually assigned to
ioapic devices by firmware.

Cc: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Cc: MUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com>
Cc: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Cc: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Roland Dreier <rdreier@cisco.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

We need to assign resources to ioapics being hot-added. This patch
changes pbus_assign_resources_sorted() to assign resources if the
ioapic has no assigned resources.
Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NMUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com>
Signed-off-by: NSatoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Signed-off-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This is needed if we wish to change the size of the resource structures.

Based on an original patch from Vivek Goyal <vgoyal@in.ibm.com>

Cc: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

A recent Stratus x86_64 platform uses a system ioapic that is a PCI device
located below a PCI bridge.  Other platforms like this may exist.

This patch fixes a problem wherein the kernel's PCI setup code moves
the ioapic to an address other than that assigned by the BIOS.  It simply
adds another exclusion (which already includes classless devices and host
bridges) to the function pbus_assign_resources_sorted so that it will not
move the ioapic.

If the ioapic is moved, the fixmap mapping to it is broken, so the OS should
leave it alone.

From: Kimball Murray <kimball.murray@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

That's what we've always historically done, and bigger windows seem to
confuse some cardbus bridges. Or something.

Alan reports that this makes the ThinkPad 600x series work properly
again: the 4kB IO window for some reason made IDE DMA not work, which
makes IDE painfully slow even if it works after DMA timeouts.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>