Yes I was wrong on this one, but after looking at the acenic I think
the current solution is not very nice to driver authors.
> If you were trying to point out the problem with what the Acenic
> driver is doind, just state that next time ok? :-)
It's more a generic problem with PCI DMA API, acenic just happens to
be the clearest victim of it @)
> Plainly, I'm going to be highly reluctant to make changes to the PCI
> dma API in 2.4.x It is already hard enough to get all the PCI drivers
> in line and using it. Suggesting this kind of change is similar to
> saying "let's change the arguments to request_irq()". We would do it
> to fix a true "people actually hit this" kind of bug, of course. Yet
> we would avoid it at all possible costs due to the disruption this
> would cause.
How about a new function (pci_nonrepresentable_address() or whatever)
that returns true when page cache contains pages that are not representable
physically as void *. On IA32 it would return true only if CONFIG_PAE is
true and there is memory >4GB.
Then the network driver could do
dev->features |= NETIF_F_HIGHDMA;
[in theory it would be possible to push it up into dev.c to avoid
bounces for highmem memory <4GB, but I don't want to teach such details
to the generic layer]
DAC support would be the next step, not necessarily one for 2.4, but perhaps
one that could be backported from 2.5 at some point.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/