achiang at hp
Nov 17, 2009, 7:20 PM
Post #1 of 2
(137 views)
Permalink
|
|
[PATCH] cciss: change Cmd_sg_list.sg_chain_dma type to dma_addr_t
|
|
A recent commit broke the ia64 build:
Author: Don Brace <brace [at] beardog>
Date: Thu Nov 12 12:50:01 2009 -0600
cciss: Add enhanced scatter-gather support.
because of this hunk:
--- a/drivers/block/cciss.h
+++ b/drivers/block/cciss.h
+struct Cmd_sg_list {
+ SGDescriptor_struct *sgchain;
+ dma64_addr_t sg_chain_dma;
+ int chain_block_size;
+};
The issue is that dma64_addr_t isn't #define'd on ia64.
The way that we're using Cmd_sg_list.sg_chain_dma is to hold an
address returned from pci_map_single().
+ temp64.val = pci_map_single(h->pdev,
+ h->cmd_sg_list[c->cmdindex]->sgchain,
+ len, dir);
+
+ h->cmd_sg_list[c->cmdindex]->sg_chain_dma = temp64.val;
pci_map_single() returns a dma_addr_t too.
This code will still work even on a 32-bit x86 build, where
dma_addr_t is defined to be a u32 because it will simply be
promoted to the __u64 that temp64.val is defined as.
Thus, declaring Cmd_sg_list.sg_chain_dma as dma_addr_t is safe.
Cc: Don Brace <brace [at] beardog>
Cc: Stephen M. Cameron <scameron [at] beardog>
Signed-off-by: Alex Chiang <achiang [at] hp>
---
This changelog is probably an analysis overkill, but I was
concerned about 32 vs 64 bit DMA addresses getting passed to the
hardware. After doing a bunch more reading, I'm satisfied that a)
we're dealing with CPU-side addresses and b) proper type
promotion occurs anyway.
If anyone wants to double-check my work, I won't be offended. ;)
I build tested this on ia64, x86_64, and i386. No gcc nor sparse
warnings. However, I didn't do any run-time testing on i386.
---
diff --git a/drivers/block/cciss.h b/drivers/block/cciss.h
index e5c63e5..1d95db2 100644
--- a/drivers/block/cciss.h
+++ b/drivers/block/cciss.h
@@ -57,7 +57,7 @@ typedef struct _drive_info_struct
struct Cmd_sg_list {
SGDescriptor_struct *sgchain;
- dma64_addr_t sg_chain_dma;
+ dma_addr_t sg_chain_dma;
int chain_block_size;
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|
