On 14 Jun 2002, Peter Osterlund wrote:
>
> cs: cb_alloc(bus 1): vendor 0x13d1, device 0xab02
> Scanning bus 01
> Found 01:00 [13d1/ab02] 000200 00
Ok, it found a regular PCI network card (000200) with a regular header
(00), and it will have read all the resources but not _allocated_ them
yet.
> PCI: Calling quirk c01d5650 for 01:00.0
> Fixups for bus 01
> PCI: Scanning for ghost devices on bus 1
> Unknown bridge resource 0: assuming transparent
> Unknown bridge resource 1: assuming transparent
> Unknown bridge resource 2: assuming transparent
> Bus scan for 01 returning with max=01
> PCI: Device 01:00.0 not available because of resource collisions
And here it calls it unavailable, because it notices that the device has
resources, but they haven't been allocated, so it assumes that lack of
allocation is due to some resource conflict.
However, it _looks_ like the lack of resource allocation is simply because
we never bothered to even try to allocate them.
Pat, your change to use "pci_do_scan_bus()" seems to have dropped the:
/* FIXME: Do we need to enable the expansion ROM? */
for (r = 0; r < 7; r++) {
struct resource *res = dev->resource + r;
if (res->flags)
pci_assign_resource(dev, r);
}
thing completely, which is the thing that actually _allocates_ and assigns
the resources.
Peter, mind adding that resource allocation loop to the "cb_alloc()"
function, inside the "list_for_each(node,&bus->devices) {" loop? Just
before the "Does this function have an interrupt at all?" line..
Alternatively, maybe that resource allocation might just be done in
"pci_enable_device()". It does kind of make sense at that point, instead
of just giving up due to unallocated resources..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 22:00:32 EST