On Wednesday 31 March 2010 04:56:53 pm Ira W. Snyder wrote: > Ok, dev_info() sounds fine. Here is the current output I produce, taking > your comments into account. Does this look ok, or are there other tweaks > I can do before resubmitting? > > [ 0.336026] pci 0000:00:00.0: host bridge window [bus 00] Maybe something like this (copying the ACPI output)? I would guess that the 00.1 bridge actually passes a range of bus numbers, to allow for plug-in cards with bridges on them. pci 0000:00:00.0 CNB20LE PCI Host Bridge (domain 0000 [bus 00]) pci 0000:00:00.1 CNB20LE PCI Host Bridge (domain 0000 [bus 01-ff]) This is way beyond nit-picking even, but I like it when drivers produce one-line "I found this device and here's what it is" output that's distinguishable from the extra debug-type info like the memory & I/O windows. > [ 0.340009] pci 0000:00:00.0: host bridge window [io 0x01f0-0x01f7] > [ 0.344008] pci 0000:00:00.0: host bridge window [io 0x03f6] > [ 0.348008] pci 0000:00:00.0: host bridge window [io 0x0170-0x0177] > [ 0.352008] pci 0000:00:00.0: host bridge window [io 0x0376] Seems surprising that these are the only ports in the 0x0-0xcfff range that are routed anywhere. I would naively expect them to be at least subtractively decoded by one of the bridges, so all the legacy builtin hardware (APICs, serial ports, etc) would still work, but the unused stuff would be available for PCI. > [ 0.356008] pci 0000:00:00.0: host bridge window [io 0xffa0-0xffaf] > [ 0.360008] pci 0000:00:00.0: host bridge window [mem 0xfc000000-0xfe8fffff] > [ 0.364009] pci 0000:00:00.0: host bridge window [mem 0xfba00000-0xfbafffff pref] > [ 0.368008] pci 0000:00:00.0: host bridge window [io 0xd000-0xdffc] > [ 0.396022] pci 0000:00:00.1: host bridge window [bus 01] > [ 0.400009] pci 0000:00:00.1: host bridge window [mem 0xfe900000-0xfebfffff] > [ 0.404009] pci 0000:00:00.1: host bridge window [mem 0xfbb00000-0xfbffffff pref] > [ 0.408008] pci 0000:00:00.1: host bridge window [io 0xe000-0xeffc] > > There are two host bridges. Bus 0 has the legacy IDE ports, plus the > onboard PCI devices. Bus 1 has the PCI devices that come from external > slots. > > > And I think this whole file probably should go under a config option, > > since it's really pretty specialized and only of interest to a few > > boards that use this chipset but don't have ACPI. > > Ok, I can easily add that. FYI, both of the SBC's that I own using this > chipset do not have ACPI support. Thanks for doing this, by the way. I'm trying hard to make the ACPI host bridge driver work well, but it's obviously not applicable for every machine. Eventually, I think it'd be nice to factor out some kind of generic "struct pci_host_bridge", which we'd create using information from ACPI, OpenFirmware, native drivers like yours, etc. Having another example like yours will help figure out how to abstract this. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
