Just bringing this up again as it's about that time of year. There's an issue with some Via southbridges (the only notable and confirmed example I have being the VT8231 on the PegasosPPC) which can be configured such that they report that they are in "PCI Native Mode", but in fact handle (and report) legacy ATA interrupts through the ISA Bridge configuration. There are several different ways you can set it up from having a single IRQ (true PCI native), to using PCI register access but with IRQ routing through a certain pair of interrupts (14/15 or 10/11) or by having real legacy ISA access (ports in the low memory ranges and the old 14/15 pair we all remember from the first ATA controllers). My problem with the driver is twofold; first, the old IDE block driver had a hack applied which singles out the Pegasos as a quirk and maps two interrupts into the "hwif" depending on the channel being set up. I wrote a simple heuristic test which checks the IDE controller and ISA bridge configuration and works out the correct IDE interrupts to use. I can submit this patch but since the IDE block layer is going the way of the dodo I see no point in it. The second and REAL problem is that I see no real way in libata to place detection of this quirk for the updated (and better) driver. I noticed a strange patch on the linuxppc-dev mailing list by a Freescale employee which changed the PCI class code of a ULI controller which somehow made the libata driver for that controller consider it a not-quite-native driver; I am not sure how that was meant to work but it was obviously a platform-specific solution. Does anyone have an idea how we can integrate this 'quirk' of the non-native native PCI mode and support two IRQs properly so we can have pata_via work on Pegasos (distros are dropping the old drivers as we speak..) -- Matt Sealey <matt@xxxxxxxxxxxxxx> Genesi, Manager, Developer Relations - 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
