Alan Cox wrote: >> all we can use is how the BIOS configured it. I suppose BIOS does it by >> issuing trial commands which I don't think adding to libata is a good idea. > > The BIOS does it by asking the hardware somehow. I traced one or two > BIOSes that far. The info is there but its not documented in the > slightest so only ACPI makes it visible via the BIOS. OIC, gawdddddddd... What was so long with just following what those AMD chips did? >> Can you please lemme know what you don't like about the current >> implementation or what other approach you have in mind? I don't like >> Nvidia PATA either but there are a lot of people using it out there. > > We seem to be able to trust the drives and BIOS ACPI data for Nvidia (at > least what I have seen), so I guess we should simply declare the cable > type unknown, 80 wire if ACPI says it is and then do the drive detect > side ? There are machines with broken BIOSen so actually the most reliable source is the UDMA timing register. On ASUS A8N-E, ACPI and UDMA timing register always concur. I think it's best to look at both not so much for accuracy but for debugging, so the following printk in the patch. + if (ap->pflags & ATA_PFLAG_INIT_GTM_VALID) + snprintf(acpi_str, sizeof(acpi_str), " (%u:%u:0x%x)", + ap->acpi_init_gtm.drive[0].dma, + ap->acpi_init_gtm.drive[1].dma, + ap->acpi_init_gtm.flags); + + ata_port_printk(ap, KERN_DEBUG, "nv_cable_detect: native=%d (0x%x) " + "BIOS=%d (0x%x) ACPI=%d%s verdict=%d\n", + native_cbl, ata66, bios_cbl, saved_udma, acpi_cbl, + acpi_str, verdict); When cable detection goes wrong, we'll at least know what all those different sources are telling. 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