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 <aacraid@xxxxxxxxxxx> 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:James.Bottomley@xxxxxxxxxxxxxxxxxxxxx] > Sent: Friday, January 11, 2008 11:41 AM > To: Salyzyn, Mark > Cc: 'linux-scsi@xxxxxxxxxxxxxxx' > 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 <aacraid@xxxxxxxxxxx> > > > > 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 ...
Attachment:
aacraid_flush_dcache4.patch
Description: aacraid_flush_dcache4.patch