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

[Ralf Baechle]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/