On Friday 02 November 2007, Alan Cox wrote: > > Using the initial GTM value is the right thing to do because both are > > trying to check firmware setting and by the time ->cable_detect runs > > the controller is already forced into PIO0 by reset. > > As we only look at the DMA bits that doesn't matter but I agree it would It does matter, http://lkml.org/lkml/2007/10/12/537 " > libata: correct handling of SRST reset sequences This potentially adds a regression for nVidia boxes (but ACPI cable detection should compensate for it): pata_amd's ->cable_detect checks UDMA timings to get the cable type (cable detection is done before the SRST) but pata_amd's ->set_piomode messes with UDMA timings. It seems that both methods need fixing. " [ Now we see that since ACPI can just dump the current settings ACPI cable detection won't help a tiny bit. ] AFAICS pata_via.c has the same problem w.r.t. ->set_piomode > be cleaner if we were more careful. Also our mode setting outside > pata_acpi doesn't touch the ACPI settings so its ok for that reason too. 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
