Alan Cox wrote: >> detection. We're basically just trying to follow what BIOS did. Maybe >> we should return ATA_CBL_PATA_MAYBE_80 unconditionally and implement > > MAYBE_80 = UNK. Yeah, right. I somehow thought it was close to "don't really know but treat as 40c" but it's more like "don't really know maybe 80c". I think implementing this as mode filter is the better approach and reflects the situation better. We can't really tell the cable type. All we know is how BIOS/firmware configured it and we're just trying to use the same transfer mode. Do you agree? Then, I'll go ahead and redo the patch and implement this mess as mode filter. >> ata_acpi_more_filter()? > > We can also use UNK intelligently in the eh code to go straight from > UDMA133/100/66 to 33 (if you don't already I've not read that logic > recently) The default behavior of the current EH code should be enough. It first decelerate one step (e.g. UDMA/133->UDMA/100) and then right to UDMA/33. With the pending speed down update patch applied, it will take at most three consecutive errors to reach UDMA/33 from any speed above that. 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
