I assume you're aware that this patch is just a subset of commit
76d78300a6eb8 which you've already pushed up to Linus. Adding Nick Cheng
(commit author) to CC so that he can go over the feedback.
James Bottomley wrote:
diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
index f4a202e..4f9ff32 100644
--- a/drivers/scsi/arcmsr/arcmsr_hba.c
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c
@@ -1380,12 +1388,13 @@ static int arcmsr_iop_message_xfer(struct
AdapterControlBlock *acb, \
case ARCMSR_MESSAGE_READ_RQBUFFER: {
unsigned long *ver_addr;
- dma_addr_t buf_handle;
uint8_t *pQbuffer, *ptmpQbuffer;
int32_t allxfer_len = 0;
+ void *tmp;
- ver_addr = pci_alloc_consistent(acb->pdev, 1032, &buf_handle);
- if (!ver_addr) {
+ tmp = kmalloc(1032, GFP_KERNEL|GFP_DMA);
GFP_DMA is pretty pointless for a buffer which never actually gets anywhere
near a DMA, isn't it?
+ ver_addr = (unsigned long *)tmp;
No cast needed from void *
+ if (!tmp) {
retvalue = ARCMSR_MESSAGE_FAIL;
goto message_out;
}
@@ -1421,18 +1430,19 @@ static int arcmsr_iop_message_xfer(struct
AdapterControlBlock *acb, \
memcpy(pcmdmessagefld->messagedatabuffer, (uint8_t *)ver_addr,
allxfer_len);
pcmdmessagefld->cmdmessage.Length = allxfer_len;
pcmdmessagefld->cmdmessage.ReturnCode =
ARCMSR_MESSAGE_RETURNCODE_OK;
- pci_free_consistent(acb->pdev, 1032, ver_addr, buf_handle);
+ kfree(tmp);
}
break;
case ARCMSR_MESSAGE_WRITE_WQBUFFER: {
unsigned long *ver_addr;
- dma_addr_t buf_handle;
int32_t my_empty_len, user_len, wqbuf_firstindex,
wqbuf_lastindex;
uint8_t *pQbuffer, *ptmpuserbuffer;
+ void *tmp;
- ver_addr = pci_alloc_consistent(acb->pdev, 1032, &buf_handle);
- if (!ver_addr) {
+ tmp = kmalloc(1032, GFP_KERNEL|GFP_DMA);
Actually, also all the code around here implies we're in atomic context,
so that GFP_KERNEL can't be right either.
Further confirmed by the fact that dma_free_coherent() was complaining
about IRQs being disabled.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
