Skip to contentSkip to conversation

drivers/net/rcpci45 DMA mapping API conversion

PATCH In review Francois Romieu 3 participants 6 messages Jan 5, 2003 – Apr 19, 2003 Network drivers

lore
Share & tools
lore

Francois Romieu

author
#0 lore raw

PATCH 1/1 drivers/net/rcpci45 DMA mapping API conversion

Greetings,

I've been asked to convert the driver while compiling, so:
- the exit paths look ok;
- it compiles;
- in rcpci45_remove_one(), I have been unable to find under which condition it would be possible to have pDpa->msgbuf set to NULL. Test removed.

Comment, test and forward to Linus if correct.

drivers/net/rclanmtl.h +2 -1
diff -pruN linux-2.5.54.orig/drivers/net/rclanmtl.h linux-2.5.54/drivers/net/rclanmtl.h
@@ -182,6 +182,7 @@ typedef struct {
 	U32 pci_addr;		/* the pci address of the adapter */
 	U32 pci_addr_len;
 
+	struct pci_dev *pci_dev;
 	struct timer_list timer;	/*  timer */
 	struct net_device_stats stats;	/* the statistics structure */
 	unsigned long numOutRcvBuffers;	/* number of outstanding receive buffers */

@@ -189,7 +190,7 @@ typedef struct {
 	unsigned char reboot;
 	unsigned char nexus;
 	PU8 msgbuf;		/* Pointer to Lan Api Private Area */
-	PU8 PLanApiPA;		/* Pointer to Lan Api Private Area (aligned) */
+	dma_addr_t msgbuf_dma;
 	PPAB pPab;		/* Pointer to the PCI Adapter Block */
 } *PDPA;
drivers/net/rclanmtl.c +2 -2
diff -pruN linux-2.5.54.orig/drivers/net/rclanmtl.c linux-2.5.54/drivers/net/rclanmtl.c
@@ -301,8 +301,8 @@ RCInitI2OMsgLayer (struct net_device *de
 	PPAB pPab;
 	U32 pciBaseAddr = dev->base_addr;
 	PDPA pDpa = dev->priv;
-	PU8 p_msgbuf = pDpa->PLanApiPA;
-	PU8 p_phymsgbuf = (PU8) virt_to_bus ((void *) p_msgbuf);
+	PU8 p_msgbuf = pDpa->msgbuf;
+	PU8 p_phymsgbuf = (PU8) pDpa->msgbuf_dma;
 
 	dprintk
 	    ("InitI2O: Adapter:0x%04ux ATU:0x%08ulx msgbuf:0x%08ulx phymsgbuf:0x%08ulx\n"
drivers/net/rcpci45.c +36 -33

156 lines not on this page · raw message

#1 lore raw
Quoted 9 lines · Francois Romieu

Greetings,

I've been asked to convert the driver while compiling, so:
- the exit paths look ok;
- it compiles;
- in rcpci45_remove_one(), I have been unable to find under which condition it would be possible to have pDpa->msgbuf set to NULL. Test removed.

Comment, test and forward to Linus if correct.

Ok, I finally got around to attacking this one. Your patch looked ok to me until I noticed one detail:

        pDpa->msgbuf = kmalloc (MSG_BUF_SIZE, GFP_DMA | GFP_KERNEL);

The GFP_DMA tag indicates that we can't just use pci_alloc_consistent in the normal way, as we lose the GFP_DMA designator.

Jeff

#2 lore raw

Re,

Jeff Garzik <[email protected]> :
[...]

Quoted 7 lines

Ok, I finally got around to attacking this one. Your patch looked ok to me until I noticed one detail:

         pDpa->msgbuf = kmalloc (MSG_BUF_SIZE, GFP_DMA | GFP_KERNEL);

The GFP_DMA tag indicates that we can't just use pci_alloc_consistent in the normal way, as we lose the GFP_DMA designator.

Does it mean the usual pci_set_dma_mask() cooking or something more elaborate ?

--
Ueimor

#3 lore raw
Quoted 5 lines · Francois Romieu

Re,

Jeff Garzik <[email protected]> :
[...]

Quoted 8 lines
Quoted 5 lines

Ok, I finally got around to attacking this one. Your patch looked ok to me until I noticed one detail:

        pDpa->msgbuf = kmalloc (MSG_BUF_SIZE, GFP_DMA | GFP_KERNEL);

The GFP_DMA tag indicates that we can't just use pci_alloc_consistent in the normal way, as we lose the GFP_DMA designator.

Does it mean the usual pci_set_dma_mask() cooking or something more elaborate ?

Reading dma_alloc_coherent() in arch/i386/kernel/pci-dma.c, it does appear that would be sufficient...

Jeff

#4 lore raw

Jeff Garzik <[email protected]> :
[...]

Quoted 1 line

Francois Romieu wrote:

[...]

Quoted 12 lines
Quoted 12 lines

Jeff Garzik <[email protected]> :
[...]

Quoted 7 lines

Ok, I finally got around to attacking this one. Your patch looked ok to me until I noticed one detail:

        pDpa->msgbuf = kmalloc (MSG_BUF_SIZE, GFP_DMA | GFP_KERNEL);

The GFP_DMA tag indicates that we can't just use pci_alloc_consistent in the normal way, as we lose the GFP_DMA designator.

Quoted 6 lines
Quoted 2 lines

Does it mean the usual pci_set_dma_mask() cooking or something more elaborate ?

Reading dma_alloc_coherent() in arch/i386/kernel/pci-dma.c, it does appear that would be sufficient...

I'll cook something like that then.
Anyway, I'm curious to know whether someone[1] can come with a specific mask for this device or (even better) say that the GFP_DMA wasn't really needed in the first place.

[1] driver claims:
** Ported to 2.1.x by Alan Cox 1998/12/9.

Any hint Mr Cox ?

--
Ueimor

#5 lore raw
In reply to Francois Romieu

Adding to my last email, I think the solution is to look at the implementation of pci_alloc_consistent and the other functions your patch calls. You may be able to get away with simply changing your pci_alloc_consistent call to

dma_alloc_coherent(&hwdev->dev, size, dma_handle, GFP_DMA | GFP_KERNEL);

Take a look at include/asm-generic/pci-dma-compat.h for how pci_alloc_consistent is implemented on most platforms.

Thanks!

Jeff