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 > 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. GTM results do change whether you call STM or not. GTM in many cases is implemented as reading the current configuration value from the controller so if you configure PIO0, it will return PIO0 timings. And, yeah, on ASUS A8N-E, if you configure PIO0, GTM answer says DMA is off. >> + * Determine cable type from UDMA configuration in @gtm. If UDMA is >> + * disabled, it returns ATA_CBL_PATA_UNK. If UDMA is enabled and >> + * faster than 33, PATA_80; otherwise, PATA_40. > > NAK > > Consider the case of a UDMA 33 capable device on an 80 wire cable. We > simply can't use the cable detect methods to prove it is 40 wire this way. > > What we actually know is > > If UDMA > 33 selected -> UDMA > 33 works > 80 wire > Short > or SATA > > If UDMA > 33 not selected Unknown > 40 wire > 80 + Drive limit > 80 + Controller limit > 80 + BIOS is set to PIO > etc > > The only case I can see you could reasonably suggest 40 wire would be > IFF the drive is capable of UDMA > 33 _and_ the ACPI mode is UDMA 33. What the function answers is not actually cable type but "according to the current configuration, using this cable type won't violate BIOS configuration" kind of answer. How the caller is to use that is the caller's responsibility. -- 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
