Hello, Alan. On 08/17/2010 07:01 PM, Alan Cox wrote: >> 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. But ata_generic grabbing a controller doesn't mean it's gonna be messed up in anyway. That's what windows does for unknown IDE controllers after all. The problem we want to avoid here is using ata_generic for a controller which already has a proper driver. >> 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. I don't really think it would be dangerous to grab intel IDE controllers with ata_generic. Again, that's what windows would do. And for sysfs unbind case, if the user specifically unbinds the controller from ata_piix, what is broken? > 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. For RZ1000, sure, but we're talking about only intel IDEs here. >>> 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. Maybe it's okay now but who's gonna remember what's going on there after five years and nobody guarantees the above would continue to hold in the future. > 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. Yeah, I think it would be better to do it in ata_generic one way or the other. Thanks. -- tejun -- 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
