An old, pre-BMDMA, "PCI IDE Controller Specification, rev 1.0, 3/4/94"
I have here says on page 3, in chapter 2.4, second and third paragraphs say:
-- When a channel is in 'compatibility' mode, the controller can either disable the first four Base Address registers (i.e.; make them not writable and return 0's when read) or leave them fully programmable. In either case the values in these registers are ignored as long as the channel is in 'compatibility' mode.
When a channel is in compatibility mode the IRQ used by the channel must be the 'compatibility' IRQ. PCI interrupt lines must not be effected by that channel's interrupt. Conversely, when the channel is in native-PCI mode the channel's interrupt should be connected to the appropriate INTx#. Compatibility IRQs should not be effected (i.e.; they should be tristated).--
> We see that the chip isnt in native mode so we defer to the legacy > scanner. Since the ports are not valid the legacy scanner doesn't find > them. > > Any thoughts on how we should handle this case Andre ?
We should ignore BARs (and reported INT#) when chip is not in native mode, but I'm sure that it breaks something else (note that I do not know any chip which honors BARs when using compatible mode; only problematic piece of hardware I know is PDC20265, but this one does not report itself as IDE hardware, so for this chip we have special cases in the code already; maybe VIA uses IRQ number specified in PCI config space instead of 14/15?). Petr Vandrovec email@example.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/