Share code between setup-bus.c and yenta_socket.c: use the write-out code of
resources to the bridge also in yenta_socket.c, as it provides useful debug
output.  In addition, it fixes the bug that the CPU-centric resource view
might need to be transferred to the PCI-centric view: setup-bus.c does that,
while yenta-socket.c did not.
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

I had some time to think about PCI assign issues in 2.6.13-rc series.

The major problem here is that we call pci_assign_unassigned_resources()
way too early - at subsys_initcall level. Therefore we give no chances
to ACPI and PnP routines (called at fs_initcall level) to reserve their
respective resources properly, as the comments in drivers/pnp/system.c
and drivers/acpi/motherboard.c suggest:

 /**
  * Reserve motherboard resources after PCI claim BARs,
  * but before PCI assign resources for uninitialized PCI devices
  */

So I moved the pci_assign_unassigned_resources() call to
pcibios_assign_resources() (fs_initcall), which should hopefully fix a
lot of problems and make PCIBIOS_MIN_IO tweaks unnecessary.

Other changes:
- remove resource assignment code from pcibios_assign_resources(), since
  it duplicates pci_assign_unassigned_resources() functionality and
  actually does nothing in 2.6.13;
- modify ROM assignment code as per Ben's suggestion: try to use firmware
  settings by default (if PCI_ASSIGN_ROMS is not set);
- set CARDBUS_IO_SIZE back to 4K as it's a wonderful stress test for
  various setups.

Confirmed by Tero Roponen <teanropo@cc.jyu.fi> (who had problems with
the 4kB CardBus IO size previously).
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

It may seem small, but most cards need much less, if any, and this not
only makes the code adhere to the comment, it seems to fix a boot-time
lockup on a ThinkPad 380XD laptop reported by Tero Roponen <teanropo@cc.jyu.fi>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The setup-bus code doesn't work correctly for configurations
with more than one display adapter in the same PCI domain.
This stuff actually is a leftover of an early 2.4 PCI setup code
and apparently it stopped working after some "bridge_ctl" changes.
So the best thing we can do is just to remove it and rely on the fact
that any firmware *has* to configure VGA port forwarding for the boot
display device properly.

But then we need to ensure that the bus->bridge_ctl will always
contain valid information collected at the probe time, therefore
the following change in pci_scan_bridge() is needed.
Signed-off-by: NIvan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

There is a slight disagreement between setup-bus.c code and traditional
x86 PCI setup wrt which recourses are invalid vs resources that are free
for further allocations.

In particular, in the setup-bus.c, if we failed to allocate some resource,
we nullify "start" and "flags" fields, but *not* the "end" one.

But x86 pcibios_enable_resources() does the following check:

	if (!r->start && r->end) {
		printk(KERN_ERR "PCI: Device %s not available because of resource collisions\n", pci_name(dev));
		return -EINVAL;

which means that the device owning the offending resource cannot be
enabled.

In particular, this breaks cardbus behind the normal decode p2p bridge -
the cardbus code from setup-bus.c requests rather large IO and MEM
windows, and if it fails, the socket is completely unavailable.  Which
is wrong, as the yenta code is capable to allocate smaller windows.
Signed-off-by: NIvan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

- Add sanity check for io[port,mem]_resource in setup-bus.c. These
  resources look like "free" as they have no parents, but obviously
  we must not touch them.
- In i386.c:pci_allocate_bus_resources(), if a bridge resource cannot be
  allocated for some reason, then clear its flags. This prevents any child
  allocations in this range, so the setup-bus code will work with a clean
  resource sub-tree.
- i386.c:pcibios_enable_resources() doesn't enable bridges, as it checks
  only resources 0-5, which looks like a clear bug to me. I suspect it
  might break hotplug as well in some cases.

From: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

When hot-plugging an I/O hierarchy that contains many bridges and leaf
devices, it's possible that there are not enough resources to start all the
device present.  If we fail to assign a resource, clear the corresponding
value in the pci_dev structure, so other code can take corrective action.
Signed-off-by: NRajesh Shah <rajesh.shah@intel.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!