Hi, On Thursday 24 July 2008, Ben Dooks wrote: > On Thu, Jul 24, 2008 at 02:52:15PM +0100, Alan Cox wrote: > > > > Ok so you've got a board reporting native mode using the legacy IRQ > > > > numbering (14/15 - or platform equivalents) ? In which case may I suggest > > > > you rewrite the header to indicate it is in legacy mode as per the BIOS > > > > guide ? > > > > > > The drivers/ide/pci/alim15x3.c driver currently has code to correctly > > > set the IRQ fields for anything that isn't SPARC. Does this mean we > > > must disable the libata driver for anything that isn't SPARC? What about > > > other boards where this device combination is present? > > > > There should be no boards where this combination is present. IRQ 0 in > > native mode means "polled". It would therefore be helpful if you would > > start considering your board as a problem special case - one we need to > > support yes - rather than trying to argue that we should break support > > for standard configurations. > > So just because we fit a chip, we're suddenyly a special case? Moving > to libata has ignored the code in the old IDE driver which ensures that > the IRQ driver is used. I have no idea how many other systems have this > same problems, but the systems we've shipped have had this chip setup > for nearly 10 years now. Please note that the recommended PATA support in kernel.org kernels is IDE subsystem and libata PATA is still considered experimental. > I admit the original fix is wrong, the change should be handled by some > form of callback or a method of passing the interrupt numbers in when > registering with the libata-sff.c driver. Seems like the good solution would be to: - add PCI HEADER quirk to claim legacy mode (as suggested by Alan) - move ALi IRQ handling code to PCI layer and then hook it into pci_get_legacy_ide_irq() Thanks, Bart -- 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
