Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs) II
On Fri, 2007-08-10 at 22:27 +0200, Andi Kleen wrote: Surely we don't need to wait until then? This is the correct fix, isn't it? (Obviously I'll split it into a generic and a pcmcia specific piece if it looks OK to everyone). It sets the PCMCIA dma_mask up correctly and introduces a DMA_MASK_NONE (I prefer that to DMA_0BIT_MASK but I can add that too if people want) and gives Alan his is_device_dma_capable() API. Patch looks good to me. No one else has commented ... shall I just submit the following two for the merge window? James - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs) II
Not in non platform code, please ... somewhere on the Janitor's list is moving the dma_mask from the bus specific devices into the generic device ... when that happens this quantity will become u64 and they won't know what to do with the NULL check. Ok filed for kernel summit - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs) II
On Fri, 2007-08-10 at 14:54 +0100, Alan Cox wrote: Ok so we do in fact need some kind of proper way to ask if a device is DMA capable ? Right now it seems to be (dev-dma_mask != NULL) I'll follow that path for now then Not in non platform code, please ... somewhere on the Janitor's list is moving the dma_mask from the bus specific devices into the generic device ... when that happens this quantity will become u64 and they won't know what to do with the NULL check. Even today, it's wrong for this to be NULL. It's a bug somewhere in the pcmcia layer. What should happen is that there should be a u64 dma_mask somewhere in struct pcmcia_device where this should be pointing. James - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs) II
Alan Cox [EMAIL PROTECTED] writes: BTW unless I'm misreading the i386 code it'll not fail here, but allocate memory. Surely that will cause failures later if you rely on it failing? If you don't rely on it then changing x86-64 will also not help you. Eww that'll do strange things. In theory I could change i386 too to return NULL in this case (dma_mask == NULL). But I wonder how how many existing PCMCIA drivers I would break this way? Probably needs more testing at least. My current patch is in ftp://ftp.firstfloor.org/pub/ak/x86_64/late-merge/patches/dma-alloc-mask Ok so we do in fact need some kind of proper way to ask if a device is DMA capable ? Right now it seems to be (dev-dma_mask != NULL) -Andi - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs) II
Ok so we do in fact need some kind of proper way to ask if a device is DMA capable ? Right now it seems to be (dev-dma_mask != NULL) I'll follow that path for now then - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs) II
Surely we don't need to wait until then? This is the correct fix, isn't it? (Obviously I'll split it into a generic and a pcmcia specific piece if it looks OK to everyone). It sets the PCMCIA dma_mask up correctly and introduces a DMA_MASK_NONE (I prefer that to DMA_0BIT_MASK but I can add that too if people want) and gives Alan his is_device_dma_capable() API. Patch looks good to me. -Andi - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs) II
On Fri, 2007-08-10 at 17:58 +0100, Alan Cox wrote:
Not in non platform code, please ... somewhere on the Janitor's list is
moving the dma_mask from the bus specific devices into the generic
device ... when that happens this quantity will become u64 and they
won't know what to do with the NULL check.
Ok filed for kernel summit
Surely we don't need to wait until then? This is the correct fix, isn't
it? (Obviously I'll split it into a generic and a pcmcia specific piece
if it looks OK to everyone).
It sets the PCMCIA dma_mask up correctly and introduces a DMA_MASK_NONE
(I prefer that to DMA_0BIT_MASK but I can add that too if people want)
and gives Alan his is_device_dma_capable() API.
James
diff --git a/drivers/pcmcia/ds.c b/drivers/pcmcia/ds.c
index a996071..b3837d3 100644
--- a/drivers/pcmcia/ds.c
+++ b/drivers/pcmcia/ds.c
@@ -23,6 +23,7 @@
#include linux/crc32.h
#include linux/firmware.h
#include linux/kref.h
+#include linux/dma-mapping.h
#define IN_CARD_SERVICES
#include pcmcia/cs_types.h
@@ -670,6 +671,9 @@ struct pcmcia_device * pcmcia_device_add(struct
pcmcia_socket *s, unsigned int f
p_dev-dev.bus = pcmcia_bus_type;
p_dev-dev.parent = s-dev.parent;
p_dev-dev.release = pcmcia_release_dev;
+ /* by default don't allow DMA */
+ p_dev-dma_mask = DMA_MASK_NONE;
+ p_dev-dev.dma_mask = p_dev-dma_mask;
bus_id_len = sprintf (p_dev-dev.bus_id, %d.%d, p_dev-socket-sock,
p_dev-device_no);
p_dev-devname = kmalloc(6 + bus_id_len + 1, GFP_KERNEL);
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 2dc21cb..0ebfafb 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -24,6 +24,8 @@ enum dma_data_direction {
#define DMA_28BIT_MASK 0x0fffULL
#define DMA_24BIT_MASK 0x00ffULL
+#define DMA_MASK_NONE 0x0ULL
+
static inline int valid_dma_direction(int dma_direction)
{
return ((dma_direction == DMA_BIDIRECTIONAL) ||
@@ -31,6 +33,11 @@ static inline int valid_dma_direction(int dma_direction)
(dma_direction == DMA_FROM_DEVICE));
}
+static inline int is_device_dma_capable(struct device *dev)
+{
+ return dev-dma_mask != NULL *dev-dma_mask != DMA_MASK_NONE;
+}
+
#ifdef CONFIG_HAS_DMA
#include asm/dma-mapping.h
#else
diff --git a/include/pcmcia/ds.h b/include/pcmcia/ds.h
index 90ef552..f047a1f 100644
--- a/include/pcmcia/ds.h
+++ b/include/pcmcia/ds.h
@@ -184,6 +184,7 @@ struct pcmcia_device {
char * prod_id[4];
+ u64 dma_mask;
struct device dev;
#ifdef CONFIG_PCMCIA_IOCTL
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs) II
BTW unless I'm misreading the i386 code it'll not fail here, but allocate memory. Surely that will cause failures later if you rely on it failing? If you don't rely on it then changing x86-64 will also not help you. Eww that'll do strange things. Ok so we do in fact need some kind of proper way to ask if a device is DMA capable ? Alan - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AMD64 dma_alloc_coherent crashes on non PCI device (was SATA open bugs) II
BTW unless I'm misreading the i386 code it'll not fail here, but allocate memory. Surely that will cause failures later if you rely on it failing? If you don't rely on it then changing x86-64 will also not help you. -Andi - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
