The chip isn't in legacy mode. We never set it to legacy mode. Legacy mode would not work. It's set to native mode. However the PCI class code does not reflect this :) The old Via driver checked the host controller configuration space, rather than trust the PCI class code and the ATA specs, it seems? Well, you would know since you wrote it? :D -- Matt Sealey <matt@xxxxxxxxxxxxxx> Genesi, Manager, Developer Relations Alan Cox wrote: >>> The right way to do this IMHO is still to use the PCI quirk side logic. >>> Unfortunately to put your legacy ports at different I/O addresses you >>> need changes which are still pending to the libata-sff code so that it >>> stops using the hardcoded ATA_PRIMARY_FOO bits. >> We can't move the IO ports. They're stuck in the PCI BAR. > > If you flag the chip up to report itself as legacy mode it'll assume > 0x1F0 etc as the IO mapping address [however the PPC then maps that onto > its I/O maps depends on what the readb/writeb etc macros do]. > > The value in the PCI BAR is ignored in legacy mode, its not relevant or > valid. Currently libata then uses a hardcoded 0x1F0/7 etc which is wrong > as it should be asking for the pci_resource() values which are correctly > set in the PCI code [and can be tweaked for arch specials if need be] > - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
