On Thu, Dec 12, 2013 at 5:46 PM, ron minnich <[email protected]> wrote: > Which is why I always worry about global changes of this sort when > they can't be tested. > > Things like this that *should* work, and look very reasonable, can at > times get nasty.
To be fair, those static pci devices should have their access mode fixed (a la pci_bus_operations) to the appropriate type instead of relying on a global assumption. I think missing some corner cases is vastly different than breaking a build. That said, I have a feeling the probing method probably needs to be tweaked to accommodate these cases in some manner. > > ron > > On Thu, Dec 12, 2013 at 3:34 PM, Stefan Reinauer > <[email protected]> wrote: >> * Kyösti Mälkki <[email protected]> [131212 16:02]: >>> Hi >>> >>> After commit 872c922 there is some trouble on PCI configuration >>> access with Asus M4A785-M. This could apply to other amdfam10 too, >>> although I have not yet received such reports. >>> >>> As the commit message stated, I had discovered that in the beginning >>> of ramstage all PCI configuration access used the IO (0xcf8) method >>> even though Kconfig specified MMCONF_SUPPORT_DEFAULT which should >>> imply all PCI config access is done with MMCONF unless IO is >>> explicitly requested. >> >> Not sure if this is relevant, but on i945 not all PCI devices are >> visible in MMCONF space. So enabling MMCONF_SUPPORT_DEFAULT there will >> break the system. >> >> Stefan >> >> >> -- >> coreboot mailing list: [email protected] >> http://www.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: [email protected] > http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
