Re: [patch] x86, voyager: fix ioremap_nocache()

* James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> > with the PAT changes, what used to be this default and careless 
> > ioremap() behavior by x86 turned into a hard cache aliasing 
> > conflict. So we pretty much _have to_ default to uncached - like all 
> > other sane architectures already did forever. This is a direct 
> > consequence of the PAT changes which were discussed on lkml.
> > 
> > But with PAT we take over from the MTRRs on x86 and using a 
> > cacheable ioremap() would give us aliasing conflicts and trouble all 
> > around the place.
> 
> I'm not saying the patch is wrong ... or that just because it broke 
> voyager it shouldn't be done. [...]

ok, but that rather crutial piece of information was not at all clear 
from your mail ... ;-)

> [...] What I'm saying is that it shouldn't have been put into the x86 
> tree without mailing list review.

... but the PAT patchset was all around lkml. The ioremap change was 
trivial, went into v2.6.25 and was discussed on lkml:

  http://lkml.org/lkml/2008/1/25/287

" that's why we changed all ioremaps to default to cache-disabled (PCD)
  in latest x86.git as well. For years the x86 architecture set the
  ioremap pagetable entries to cacheable by default and only the MTRRs
  (and the BIOS writers) saved us from trouble. Now we try to be a bit
  more defensive and avoid "BIOS bug causes only Linux to crash and burn
  while other OSs work fine" type of scenarios. "

i could have included the actual patch in that mail i guess - but this 
was hardly an unreviewed change and you never showed interest in the PAT 
threads on lkml (or much interest in x86 threads for that matter) so 
would it have made any difference in practice?

The commit was mentioned in the pull request to Linus as well, which was 
Cc:-ed to lkml. The commit was upstream about 3 months before you 
noticed that it broke Voyager.

But, we'd not mind at all posting 1000 x86.git patches to lkml (or 
another list) every 3 months (or more frequently), if people request 
that.

	Ingo