[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B8029FA.2000404@gmail.com>
Date: Sat, 20 Feb 2010 12:29:14 -0600
From: Robert Hancock <hancockrwd@...il.com>
To: linux-kernel <linux-kernel@...r.kernel.org>,
netdev <netdev@...r.kernel.org>
Subject: NETIF_F_HIGHDMA misuse in networking drivers?
Was just part of a discussion in another thread talking about 64-bit DMA
support issues where NETIF_F_HIGHDMA came up. I was originally under the
impression that this flag indicated the device supported 64-bit DMA
addressing. However, from looking at the code that checks for it (and,
well, the actual comment for the flag) it really means "can access
highmem" which has nothing to do with 64-bit at all. And if there's no
highmem (like on x86_64) it has no effect at all.
From looking at some drivers, however, it seems a lot of others had
similar confusion, as they are doing things like setting NETIF_F_HIGHDMA
conditionally on whether setting 64-bit DMA mask succeeds:
drivers/net/8139cp.c:
if (pci_using_dac)
dev->features |= NETIF_F_HIGHDMA;
drivers/net/jme.c:
if (jme->dev->features & NETIF_F_HIGHDMA)
rxdesc->desc1.flags = RXFLAG_64BIT;
drivers/net/forcedeth.c:
if (dma_64bit) {
if (pci_set_dma_mask(pci_dev, DMA_BIT_MASK(39)))
dev_printk(KERN_INFO, &pci_dev->dev,
"64-bit DMA failed, using
32-bit addressing\n");
else
dev->features |= NETIF_F_HIGHDMA;
(the last one is extra funny because it keeps saying 64-bit when it's
really only 39-bit..)
The net result is that a lot of drivers aren't setting the HIGHDMA flag
where they should, and thus on architectures where highmem exists,
resulting in a bunch of unnecessary copying.
Assuming my interpretation is correct, I could try and fix up some of
this mess.. any comments?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists