[PATCH] libata-sff: Fix documentation

[PATCH] libata-sff: Fix documentation

[Alan Cox]

Code moved to ioread/iowrite but the comment didn't
Also note a posting issue

Signed-off-by: Alan Cox <alan@redhat.com>

diff -u --exclude-from /usr/src/exclude --new-file --recursive linux.vanilla-2.6.23rc6-mm1/drivers/ata/libata-sff.c linux-2.6.23rc6-mm1/drivers/ata/libata-sff.c
--- linux.vanilla-2.6.23rc6-mm1/drivers/ata/libata-sff.c	2007-09-18 15:32:51.000000000 +0100
+++ linux-2.6.23rc6-mm1/drivers/ata/libata-sff.c	2007-09-18 16:18:05.000000000 +0100
@@ -257,7 +261,7 @@
 	dmactl = ioread8(ap->ioaddr.bmdma_addr + ATA_DMA_CMD);
 	iowrite8(dmactl | ATA_DMA_START, ap->ioaddr.bmdma_addr + ATA_DMA_CMD);
 
-	/* Strictly, one may wish to issue a readb() here, to
+	/* Strictly, one may wish to issue an ioread8() here, to
 	 * flush the mmio write.  However, control also passes
 	 * to the hardware at this point, and it will interrupt
 	 * us when we are to resume control.  So, in effect,
@@ -267,6 +271,9 @@
 	 * is expected, so I think it is best to not add a readb()
 	 * without first all the MMIO ATA cards/mobos.
 	 * Or maybe I'm just being paranoid.
+	 *
+	 * FIXME: The posting of this write means I/O starts are
+	 * unneccessarily delayed for MMIO
 	 */
 }
 

Re: [PATCH] libata-sff: Fix documentation

[Jeff Garzik]

Alan Cox wrote:
> Code moved to ioread/iowrite but the comment didn't
> Also note a posting issue
> 
> Signed-off-by: Alan Cox <alan@redhat.com>
> 
> diff -u --exclude-from /usr/src/exclude --new-file --recursive linux.vanilla-2.6.23rc6-mm1/drivers/ata/libata-sff.c linux-2.6.23rc6-mm1/drivers/ata/libata-sff.c
> --- linux.vanilla-2.6.23rc6-mm1/drivers/ata/libata-sff.c	2007-09-18 15:32:51.000000000 +0100
> +++ linux-2.6.23rc6-mm1/drivers/ata/libata-sff.c	2007-09-18 16:18:05.000000000 +0100
> @@ -257,7 +261,7 @@
>  	dmactl = ioread8(ap->ioaddr.bmdma_addr + ATA_DMA_CMD);
>  	iowrite8(dmactl | ATA_DMA_START, ap->ioaddr.bmdma_addr + ATA_DMA_CMD);
>  
> -	/* Strictly, one may wish to issue a readb() here, to
> +	/* Strictly, one may wish to issue an ioread8() here, to
>  	 * flush the mmio write.  However, control also passes
>  	 * to the hardware at this point, and it will interrupt
>  	 * us when we are to resume control.  So, in effect,
> @@ -267,6 +271,9 @@
>  	 * is expected, so I think it is best to not add a readb()
>  	 * without first all the MMIO ATA cards/mobos.
>  	 * Or maybe I'm just being paranoid.
> +	 *
> +	 * FIXME: The posting of this write means I/O starts are
> +	 * unneccessarily delayed for MMIO

applied