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

Ralf Baechle
2007-12-06T15:25:09Z

On Thu, Dec 06, 2007 at 12:32:54PM +0000, Ralf Baechle wrote:

> > > What I don't understand is thus why you are calling resource_to_bus on 0x1f0
> > > which is -not- a resource value, but is already a BAR value...
> >
> > 0x1f0 is resource value on MIPS Cobalt.
> > All RAW BAR values contain the offset(0x10000000) on it.
>
> In arch/mips/cobalt/pci.c:
>
> static struct resource cobalt_io_resource = {
> .start = 0x1000,
> .end = GT_DEF_PCI0_IO_SIZE - 1,
> .name = "PCI I/O",
> .flags = IORESOURCE_IO,
> };
>
> static struct pci_controller cobalt_pci_controller = {
> [...]
> .io_resource = &cobalt_io_resource,
> .io_offset = 0 - GT_DEF_PCI0_IO_BASE,
> };
>
> The .io_offset initialization looks odd; no other platform is trying to
> use a negative offset here. I think there was something odd with the
> Galileo GT-64111 which (unlike its later sucessors such as the GT-64120)
> passes memory accesses in the range 0x10000000 ... 0x11ffffff to the PCI
> bus unmodified. That is for example a load or store to physical address
> 0x100003f8 will become an I/O port access to 0x100003f8.
>
> I hope this is just a missconfiguration of the GT-64111, time for manual
> reading.

The GT-64120 has remapping register which the GT-64111 is lacking. So
the way things are I don't see how it would be possibly to generate an
I/O port address below GT_DEF_PCI0_IO_BASE (0x10000000) on that system
controller.

Which of course mean any sort of device that requires legacy I/O port
addressing is out of question unless one intentionally (ab-)uses aliases
due to only partial decoding of the I/O port address. Which would mean
no chance of using legacy I/O port devices with the Galileo.

There must be something I'm missing here, I just can't believe somebody
could possibly design such a lunatic system controller.

Ralf