> > 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:

" 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.