Re: [PATCH] video: fbdev: atyfb: only use ioremap_uc() on i386 and ia64

[Christoph Hellwig]

On Mon, Nov 11, 2019 at 08:22:50PM +0100, Arnd Bergmann wrote:
> ioremap_uc() is only meaningful on old x86-32 systems with the PAT
> extension, and on ia64 with its slightly unconventional ioremap()
> behavior, everywhere else this is the same as ioremap() anyway.
> 
> Change the only driver that still references ioremap_uc() to only do so
> on x86-32/ia64 in order to allow removing that interface at some
> point in the future for the other architectures.
> 
> On some architectures, ioremap_uc() just returns NULL, changing
> the driver to call ioremap() means that they now have a chance
> of working correctly.

So this whole area is a bit of a mess.  ioremap_uc on ia64 is brand
new in this cycle, for ia64-internal users that were previously
using ioremap_nocache.  And ioremap_nocache was identical to ioremap
everywhere but ia64.  So I think we can safely skip ia64 in the ifdef
if we go down that route.

But also on x86 I'd actually rather prefer killing off this only mainline
user of ioremap_uc.  It was added by Luis in commit 3cc2dac5be3f
("drivers/video/fbdev/atyfb: Replace MTRR UC hole with strong UC",
which looks like an optimization of MTRR usage.  I feel like I really
don't understand the point there, but it also seems a pity to keep
the API around just for that.

That being said linux-next added another call to ioremap_uc in
drivers/mfd/intel-lpss.c, so it looks like the API might have to stay.

So I guess modulo excluding ia64 your patch looks fine, and should go
along something like the one below.  I'll happily carry them in the
ioremap tree with the right ACKs.

---