[PATCH 1/1] aacraid: add call to flush_kernel_dcache_page for architectures that require it (take 2)

[Salyzyn, Mark]

The reason for the guard was for Linux Distributions that had limited their 
list of exported APIs on architectures that did *not* require the 
flush_kernel_dcache_page ... Sorry for not filtering out Distribution kernel 
issues into the list! :-)

Dropped guard in the enclosed patch.

This attached patch is against current scsi-misc-2.6.

ObligatoryDisclaimer: Please accept my condolences regarding Outlook's handling 
of patch attachments (inline gets damaged, use attachment).

Signed-off-by: Mark Salyzyn <[EMAIL PROTECTED]>

 aachba.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff -ru a/drivers/scsi/aacraid/aachba.c b/drivers/scsi/aacraid/aachba.c
--- a/drivers/scsi/aacraid/aachba.c     2008-01-11 14:38:53.342378372 -0500
+++ b/drivers/scsi/aacraid/aachba.c     2008-01-11 14:39:39.364534313 -0500
@@ -31,9 +31,9 @@
 #include <linux/slab.h>
 #include <linux/completion.h>
 #include <linux/blkdev.h>
-#include <linux/dma-mapping.h>
 #include <asm/semaphore.h>
 #include <asm/uaccess.h>
+#include <linux/highmem.h> /* For flush_kernel_dcache_page */

 #include <scsi/scsi.h>
 #include <scsi/scsi_cmnd.h>
@@ -366,6 +366,7 @@
        if (buf && transfer_len > 0)
                memcpy(buf + offset, data, transfer_len);

+       flush_kernel_dcache_page(kmap_atomic_to_page(buf - sg->offset));
        kunmap_atomic(buf - sg->offset, KM_IRQ0);

 }

Sincerely -- Mark Salyzyn

> -----Original Message-----
> From: James Bottomley [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 11, 2008 11:41 AM
> To: Salyzyn, Mark
> Cc: 'linux-scsi@vger.kernel.org'
> Subject: Re: [PATCH 1/1] aacraid: add call to
> flush_kernel_dcache_page for architectures that require it.
>
> On Tue, 2008-01-08 at 12:09 -0800, Salyzyn, Mark wrote:
> > Some architectures require a call to
> flush_kernel_dcache_page for processor spoofed DMA operations.
> >
> > This attached patch is against current scsi-misc-2.6.
> >
> > ObligatoryDisclaimer: Please accept my condolences
> regarding Outlook's handling of patch attachments (inline
> gets damaged, use attachment).
> >
> > Signed-off-by: Mark Salyzyn <[EMAIL PROTECTED]>
> >
> >  aachba.c |    5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff -ru a/drivers/scsi/aacraid/aachba.c
> b/drivers/scsi/aacraid/aachba.c
> > --- a/drivers/scsi/aacraid/aachba.c     2008-01-08
> 15:01:21.503932722 -0500
> > +++ b/drivers/scsi/aacraid/aachba.c     2008-01-08
> 15:02:35.849634368 -0500
> > @@ -31,9 +31,9 @@
> >  #include <linux/slab.h>
> >  #include <linux/completion.h>
> >  #include <linux/blkdev.h>
> > -#include <linux/dma-mapping.h>
> >  #include <asm/semaphore.h>
> >  #include <asm/uaccess.h>
> > +#include <linux/highmem.h> /* For flush_kernel_dcache_page */
> >
> >  #include <scsi/scsi.h>
> >  #include <scsi/scsi_cmnd.h>
> > @@ -366,6 +366,9 @@
> >         if (buf && transfer_len > 0)
> >                 memcpy(buf + offset, data, transfer_len);
> >
> > +#ifdef ARCH_HAS_FLUSH_ANON_PAGE
> > +       flush_kernel_dcache_page(kmap_atomic_to_page(buf -
> sg->offset));
> > +#endif
>
> This #ifdef/#endif guard is unnecessary ... flush_kernel_dcache_page()
> is available on all architectures (it's a nop on most).
>
> However, ARCH_HAS_FLUSH_ANON_PAGE is the wrong guard anyway ... that's
> for the flush_anon_page() function ...

aacraid_flush_dcache4.patch
Description: aacraid_flush_dcache4.patch