Re: [PATCHSET] libata: update timing and fix pata_amd transfer mode selection

[Jeff Garzik <jeff@garzik.org>]

Tejun Heo wrote:
> Hello,
> 
> This patchset cleans up and improves PATA timing related code and fix
> pata_amd transfer mode selection on top of the improvements.  This
> patchset contains the following tweleve patches.
> 
>  0001-ata_generic-unindent-loop-in-generic_set_mode.patch
>  0002-libata-export-xfermode-PATA-timing-related-functi.patch
>  0003-libata-clean-up-xfermode-PATA-timing-related-stuf.patch
>  0004-libata-kill-ata_id_to_dma_mode.patch
>  0005-libata-xfer_mask-is-unsigned-int-not-unsigned-long.patch
>  0006-libata-separate-out-ata_acpi_gtm_xfermask-from-pa.patch
>  0007-libata-fix-ata_acpi_gtm_xfermask.patch
>  0008-libata-implement-ata_timing_cycle2mode-and-use-it.patch
>  0009-libata-implement-ata_acpi_init_gtm.patch
>  0010-libata-reimplement-ata_acpi_cbl_80wire-using-ata_.patch
>  0011-libata-add-ATA_CBL_PATA_IGN.patch
>  0012-pata_amd-update-mode-selection-for-NV-PATAs.patch
> 
> 0001-0005 are clean ups of timing handling code.  0006-0008 unifies
> timing handling code in libata-acpi.c and pata_acpi.c with the core
> timing code.
> 
> 0009 implements initial GTM caching.  I thought about moving this to
> LLDs but it's too much hassle.  GTM is host wide and doing it from
> ->error_handler would require cross-port synchronization.  Left
> alternative is adding a separate hook.  Simply doing it during ACPI
> attach is simpler.
> 
> 0010 reimplements ata_acpi_cbl_80wire() using ata_acpi_gtm_xfermask().
> This new function takes @gtm argument.  Both users (pata_via and
> pata_amd) are converted to pass initial GTM.
> 
> 0011 implements ATA_CBL_PATA_IGN which tells libata to ignore cable
> type and supporess all related handling.
> 
> 0012 updates mode selection for NV PATA controllers.  We just can't
> tell what cable is attached on the controller either from host or
> drive side.  So, for those controllers, pata_amd just sets cable type
> to ATA_CBL_PATA_IGN and use ->mode_filter to limit transfer mode
> according to BIOS/ACPI boot configuration.  If that fails (not
> likely), pata_amd simply sets the highest allowed speed and let EH
> figure out the mess.  With recent updates, EH should be able to figure
> it out pretty soon.

overall this seems pretty sane...  but I lean towards applying it in 
2.6.25 rather than 2.6.24, since we are fairly deep into 2.6.24-rc at 
this point, with little time to test these and the speed down changes to 
ensure no last-minute breakage.