in pci_fixup_parent_subordinate_busnr() we will only reassign bus numbers
if pcibios_assign_all_busses() returns 1.
If we got to pci_fixup_parent_subordinate_busnr() and
pcibios_assign_all_busses() returns 0, should we not print out some
warning since we most likely got here because the bios didn't init things
properly?
I came across this on an embedded system in which we had a cardbus
controller behind a P2P bridge. The bios did not reserve any bus numbers
for the cardbus controller like linux does. So I ended up with:
03:04.0 CardBus bridge: Texas Instruments PCI4510 PC card Cardbus Controller (rev 03)
Flags: bus master, medium devsel, latency 0, IRQ 18
Memory at 00000000bb100000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=03, secondary=04, subordinate=07, sec-latency=176
Memory window 0: b9000000-bafff000
Memory window 1: 9dc00000-9efff000 (prefetchable)
I/O window 1: 00000000-00000003
16-bit legacy interface ports at 0001
and the P2P bridge:
00:11.0 PCI bridge: Pericom Semiconductor PCI to PCI Bridge (rev 02) (prog-if 00 [Normal decode])
Flags: bus master, 66Mhz, medium devsel, latency 0
Bus: primary=00, secondary=03, subordinate=04, sec-latency=0
I/O behind bridge: 00efe000-00ffdfff
Memory behind bridge: b6000000-bb7fffff
Prefetchable memory behind bridge: 000000008fc00000-000000009db00000
Capabilities: [dc] Power Management version 1
Capabilities: [b0] Slot ID: 0 slots, First-, chassis 00
Seems like a case we should warn about or not update the cardbus
controller's subordinate number if pcibios_assign_all_busses() returns 0.
- kumar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
