On Saturday 03 November 2007, Bartlomiej Zolnierkiewicz wrote: > 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 s/after/before/ of course > 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
