Re: [PATCH v2] ata: libata-core: Ignore forced transfer modes the host does not support

[Damien Le Moal <dlemoal@kernel.org>]

On 2026/10/15 21:49, Rand Deeb wrote:
> The libata.force parameter can force a transfer mode (pio0-6, mwdma0-4,
> udma0-7) for a port or device. ata_force_xfermask() applies it in
> ata_do_set_mode() right after ata_dev_xfermask() has limited the device
> masks to what the host supports. It replaces those masks with the forced
> mode without checking the host masks, so a mode the controller does not
> support is passed to the driver's ->set_piomode() or ->set_dmamode().
> 
> Several PATA drivers rely on the host masks to keep the mode number in
> range when indexing their timing tables. ata_piix, pata_efar,
> pata_it8213, pata_oldpiix, pata_radisys and pata_rdc declare ATA_PIO4
> and ATA_MWDMA12_ONLY, index a five-entry PIO timing table with
> pio_mode - XFER_PIO_0, and index a three-entry needed_pio[] table with
> dma_mode - XFER_MW_DMA_0. Booting with libata.force=pio5, pio6, mwdma3
> or mwdma4 makes them read past those tables, use the values read as
> further indices into the timing table, and write the result to the
> controller's timing registers.
> 
> Make ata_force_xfermask() skip, with a warning, a forced transfer mode
> that is not in the port's PIO, MWDMA or UDMA mask, and keep looking for
> an earlier matching libata.force entry, as it already does for entries
> that do not apply to the device. With libata.force=pio4,1.0:pio5 on a
> PIO4 host, device 1.0 now gets pio4 instead of pio5. Forcing a mode the
> host supports still works as before, including a mode that
> ata_dev_xfermask() removed for the device or cable.
> 
> Found by Linux Verification Center (linuxtesting.org) with SVACE.
> 
> Fixes: 332673257056 ("libata: implement libata.force module parameter")
> Signed-off-by: Rand Deeb <rand.sec96@gmail.com>

Looks good.

Reviewed-by: Damien Le Moal <dlemoal@kernel.org>


-- 
Damien Le Moal
Western Digital Research