Re: Please revert: PCI: fix IDE legacy mode resources

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> 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.

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.