> ata_piix already has list of all the devices it supports, so maybe > it's safe to grab all intel IDE devices from ata_generic? ata_piix I can't guarantee that and I'm not sure I can find anyone at Intel with that deep a knowledge of the earliest chip errata. > always has higher priority than ata_generic anyway and if a device > isn't grabbed by ata_piix, we don't lose anything by grabbing it from > ata_generic. Priority only works if you know what is there to use, and the piix one is for example broken if you change the bindings with sysfs. You don't for example want to forget to compile in one driver and get generic when that is unsafe. The extreme example would be if you have ata_generic binding to all devices and you forgot to compile in RZ1000 support. On the relevant board that just ate your file system. So the grab it all approach was dismissed. > > Is it documented ? The instructions it was written to came from the > > people who do the chips. > > Yeap, that's much better, but I still think it would be better to > avoid such detection magics if possible. Well yes but the logic is simple. 0xF8 is non zero on all later Intel ATA PCI chipsets 0x40 is writable on all earlier Intel ATA PCI chipsets, and zero + non writable on the IDE-R devices. The other thing I did consider was submitting an Intel IDE-R driver that contained the check and matched IDE CLASS & vendor == INTEL. That has the advantage of not getting autoloaded unnecessarily so easily, but means we have another driver. Alan -- 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
