[PATCH] PCI: pci_enable_device vs bridges bugs

Bug #1 (found by Jay Estabrook).
On Alpha, under certain circumstances the firmware may close the IO
window of PCI-to-PCI bridge even if there is IO behind.
This wouldn't be a problem - linux PCI setup code does set up this
window properly, but in addition the firmware clears the IO-enable
bit in the PCI_COMMAND register of the bridge.
Since we don't call pci_enable_* routines for bridges in non-hotplug
path, we end up with disabled IO. Fixed by adding pci_enable_bridges()
to pci_assign_unassigned_resources().
Architectures which don't use the latter, but do use other setup-bus
code (parisc?) also should call pci_enable_bridges() for each root bus.

Bug #2 (closely related to #1).
As it turns out, pci_enable_device() doesn't work for bridges at all,
only for regular devices (header type 0) due to 0x3f mask passed to
pci_enable_device_bars(). The mask should be (1 << PCI_NUM_RESOURCES) - 1.

Bug #3 (quite a few archs, including i386).
pcibios_enable_device() does only check first 6 resources (regardless
of the mask) to decide whether or not to enable IO and MEM.
Bridge resources start at 7.

#2 and #3 affect hotplug. I wonder, has anybody ever tried *bridged*
PCI card behind a hot-plug controller?

drivers/pci/pci.c

@@ -359,7 +359,7 @@ pci_enable_device_bars(struct pci_dev *dev, int bars)
 int
 pci_enable_device(struct pci_dev *dev)
 {
-	return pci_enable_device_bars(dev, 0x3F);
+	return pci_enable_device_bars(dev, (1 << PCI_NUM_RESOURCES) - 1);
 }
 
 /**

drivers/pci/setup-bus.c

@@ -530,6 +530,8 @@ pci_assign_unassigned_resources(void)
 	for(ln=pci_root_buses.next; ln != &pci_root_buses; ln=ln->next)
 		pci_bus_size_bridges(pci_bus_b(ln));
 	/* Depth last, allocate resources and update the hardware. */
-	for(ln=pci_root_buses.next; ln != &pci_root_buses; ln=ln->next)
+	for(ln=pci_root_buses.next; ln != &pci_root_buses; ln=ln->next) {
 		pci_bus_assign_resources(pci_bus_b(ln));
+		pci_enable_bridges(pci_bus_b(ln));
+	}
 }