Messages in this thread | | | Date | Sun, 27 Apr 2008 15:52:02 -0700 | From | "H. Peter Anvin" <> | Subject | Re: [patch] x86, voyager: fix ioremap_nocache() |
| |
David Miller wrote: > From: Jeff Garzik <jeff@garzik.org> > Date: Sun, 27 Apr 2008 18:39:24 -0400 > >> I disagree with this semantics change. A number of code places _and >> drivers_ GET IT RIGHT, and these are all broken now? > > [ Note, James's patch that you quoted is about mapping DMA > memory, in dma_declare_coherent_memory(), rather than devices. > But I know what you are trying to talk about Jeff. :-) ] > > Wrt. ioremap() semanics, it is important to realize that if > the implementation of this on x86 has been giving non-cached > I/O mappings out up until recently, you can expect that there > are hundreds of drivers that might now be broken. > > That's the sad fact of the ubiquity of x86, and it doesn't matter how > we defined the API is some document. > > Anyways, my point is that this angle should be strongly considered in > any discussion about ioremap() behavior. >
There are pretty much three reasons to default to uncached, as far as I understand:
1. De facto historical practice (follow the MTRRs); 2. Conservatism (failure mode less drastic); 3. Compatibility with other architectures.
Arguably, the right thing is to not even have ioremap() anymore, just ioremap_{cache,nocache,wc} and consider any unconverted ioremap() as a flag to audit that particular piece of code.
I don't think that can be done "instantly", though, so defaulting ioremap() to uncached (as it apparently has been on other arches already?) is the conservative option in the meantime.
-hpa
| |