Re: [PATCH 2/4] libata: Drain data on errors

[Elias Oltmanns <eo@nebensachen.de>]

Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> From: Alan Cox <alan@redhat.com>
>
> If the device is signalling that there is data to drain after an error we
> should read the bytes out and throw them away. Without this some devices
> and controllers get wedged and don't recover.
>
> Based on earlier work by Mark Lord
>
> Signed-off-by: Alan Cox <alan@redhat.com>
> ---
> diff --git a/drivers/ata/pata_pcmcia.c b/drivers/ata/pata_pcmcia.c
> index 02b596b..f08d34d 100644
> --- a/drivers/ata/pata_pcmcia.c
> +++ b/drivers/ata/pata_pcmcia.c
[...]
> @@ -126,6 +126,37 @@ static unsigned int ata_data_xfer_8bit(struct ata_device *dev,
>  	return buflen;
>  }
>  
> +/**
> + *	pcmcia_8bit_drain_fifo - Stock FIFO drain logic for SFF controllers
> + *	@qc: command
> + *
> + *	Drain the FIFO and device of any stuck data following a command
> + *	failing to complete. In some cases this is neccessary before a
> + *	reset will recover the device.
> + *
> + */
> + 
> +void pcmcia_8bit_drain_fifo(struct ata_queued_cmd *qc)
> +{
> +	int count;
> +	struct ata_port *ap;
> +
> +	/* We only need to flush incoming data when a command was running */
> +	if (qc == NULL || qc->dma_dir == DMA_TO_DEVICE)
> +		return;
> +
> +	ap = qc->ap;
> +
> +	/* Drain up to 64K of data before we give up this recovery method */
> +	for (count = 0; (ap->ops->sff_check_status(ap) & ATA_DRQ)
> +							&& count < 65536;)

Missing count++. Sorry for not spotting that in the previous round.

Regards,

Elias