On Wed, Mar 31, 2010 at 03:32:09PM -0600, Bjorn Helgaas wrote: > On Wednesday 31 March 2010 12:45:14 pm Ira W. Snyder wrote: > > On Wed, Mar 31, 2010 at 12:13:46PM -0600, Bjorn Helgaas wrote: > > > On Wednesday 31 March 2010 10:38:42 am Ira W. Snyder wrote: > > > > The CNB20LE might also be used in systems that *do* have ACPI, and in > > > that case, I think we should use ACPI rather than read the info out of > > > the hardware. I expect that's what Windows will do, and Linux should > > > do the same as Windows when it's practical. Also, that's what the BIOS > > > writers expect the OS to do, and _CRS is the logical place for them to > > > put platform-specific workarounds. > > > > Is there any way to detect if we do have ACPI and shouldn't run this > > quirk? How? > > Probably check "acpi_disabled". > Ok, I'll give this a shot. > > > > + pci_read_config_byte(dev, 0x44, &fbus); > > > > + pci_read_config_byte(dev, 0x45, &lbus); > > > > + dev_dbg(&dev->dev, "CNB20LE: busses: %d to %d\n", fbus, lbus); > > > > > > Please print the bus number, I/O port, and memory ranges in the same > > > format used by %pR, e.g., "[bus 00-ff]", etc. You might as well use > > > text similar to that in arch/x86/pci/acpi.c, e.g., "host bridge window". > > > > Should these have the "window" text that IORESOURCE_WINDOW would print, > > too? Just for IORESOURCE_(MEM|IO), or for IORESOURCE_BUS too? > > Oh, I forgot about the %pR "window" piece. We don't actually use > that yet, so I'd just make it match what we do have today, e.g., > > pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7] > pci_root PNP0A03:00: host bridge window [mem 0x0c000000-0xffffffff] > > Obviously, yours will have PCI dev strings like "pci 0000:00:00.0" > instead of "pci_root PNP0A03:00". > > Please use it for the bus range, too. I have a couple patches in flight > somewhere that will make us print this for ACPI host bridges: > > ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) > > Oh, and I also forgot to mention that I think this information is > important enough to use dev_info() rather than dev_dbg(). The dev_dbg() > is compiled out completely unless CONFIG_PCI_DEBUG is set, so I usually > use "dev_printk(KERN_DEBUG, ...)" for things I want to be in dmesg but > not on the console. > 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] [ 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] [ 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 the review, Ira -- 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
