kernel.git/drivers/pci/setup-bus.c, branch linux-2.6.15.y

cardbus: limit IO windows to 256 bytes

2005-10-23T23:31:16Z

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: Linus Torvalds

[PATCH] yenta: share code with PCI core

2005-09-09T20:57:47Z

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: Dominik Brodowski Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] x86: pci_assign_unassigned_resources() update

2005-08-30T18:14:48Z

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 (who had problems with the 4kB CardBus IO size previously). Signed-off-by: Linus Torvalds

Only pre-allocate 256 bytes of cardbio IO range

2005-08-26T17:40:10Z

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 Signed-off-by: Linus Torvalds

[PATCH] PCI: remove PCI_BRIDGE_CTL_VGA handling from setup-bus.c

2005-07-29T20:12:51Z

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: Ivan Kokshaysky Signed-off-by: Greg Kroah-Hartman Signed-off-by: Linus Torvalds

[PATCH] yet another fix for setup-bus.c/x86 merge

2005-07-06T23:12:58Z

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: Ivan Kokshaysky Signed-off-by: Linus Torvalds

[PATCH] PCI: pci_assign_unassigned_resources() on x86

2005-07-01T20:35:50Z

- 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 Signed-off-by: Greg Kroah-Hartman

[PATCH] acpi bridge hotadd: Remove hot-plugged devices that could not be allocated resources

2005-06-28T04:52:41Z

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: Rajesh Shah Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

Linux-2.6.12-rc2

2005-04-16T22:20:36Z

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!