On Tue, Jul 13, 2010 at 09:21:25AM -0700, Jesse Barnes wrote:
> Another way of doing it, that would be slightly more general, would be
> to include these ops in dev_archdata like we do for dma_ops.
>
> As Greg pointed out though, the big downside is now we have two ways of
> doing the same thing. We'd like to avoid a proliferation of basic
> functions like this if we can.
>
> Adding a dev argument to the read/write functions would help other
> arches as well, but would be huge flag day (thought it's come up several
> times before). But it doesn't address this specific case very well
> unless some bus specific hooks were added like you're doing here.
It's never going to happen. Linus has vetoed it on several occasions.
What you can do is abuse the iomap/io{read,write}{8,16,32} interfaces to
sort this out. Because iomap has to cope with port addresses as well
as memory addresses, the ioread8 (et al) functions are allowed to be a
bit more complex.
Take a look at arch/parisc/lib/iomap.c for an example of how I solved a
similar problem. Basically, you construct a completely virtual address
space, and chop it up into sections that let you know, given a pointer,
how to access that pointer.
There's an unwritten rule that every valid ioremap() pointer must be
a valid iomap() pointer (ie if you call ioremap() and then pass the
pointer to iowrite16(), it must work), but the converse is not true.
You'll still have to convert some drivers to use ioreadX/iowriteX
instead of read[bwl]/write[bwl], but that's generally acceptable
to driver authors. The patch you proposed in the first email really
wouldn;t be acceptable.
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
