On Sunday 09 December 2007, Benjamin Herrenschmidt wrote: > > > If that is the case though (that is it can't issue low ioport cycles), > > how would have the fd6e7321... worked in the first place ? Hrm... > > strange. My understanding is that all that patch does is put junk in the > > pci_dev resource structures :-) Maybe that's enough to cause the PCI > > layer later on to be unhappy about them and reassign the BARs to some > > place that works ? In which case, you are right, a better approach is a > > quirk on this specific platform, or even better, mark 0...0x10000000 > > busy in ioport_resources and let the generic code clash & re-assign... > > .../... > > In fact, I see a deeper problem with Bart's original patch that moved > the "fixup" the PCI probe.
I don't remember changing anything there, could you remind me what it was exactly (commit number or patch name)? > The code now replaces the content of the resource structures with the > hard-decoded legacy addresses for any IDE controller in legacy mode, > just losing whatever was there (the real BAR value). > > On some platforms, like PowerPC (and it might be the same problem MIPS > has, I don't know for sure), we have a quirk that puts those controller > back into native mode. But so far, those quirks didn't change the > resources as they were supposed to contain the proper BAR values that > would, from then, be used. > > Now that those values have been overriden in the resources, when the > controller is switched to native mode, it will answer to the BAR values > that no longer match the content of the resources and the driver will > fail. > > So I think we have a deeper breakage here. I'll dig some machines for > which we do that tomorrow and see what exactly is going on. It's mostly > older machines so if there's a breakage, it has easily gone under the > radar. > > I suspect any platform with such a quirk to turn IDE controllers into > native mode will now -also- need to put back the BAR values in the > struct resource, and do so -before- the platform fixup happens, that is > from a header quirk. > > Cheers, > Ben. -- 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/
