On 3/8/23 22:34, Arnd Bergmann wrote:
0On Wed, Mar 8, 2023, at 21:01, Luis Chamberlain wrote:
On Wed, Mar 08, 2023 at 09:07:07PM +0800, Baoquan He wrote:
From: Arnd Bergmann <arnd@xxxxxxxx>
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.
Signed-off-by: Arnd Bergmann <arnd@xxxxxxxx>
Signed-off-by: Baoquan He <bhe@xxxxxxxxxx>
Cc: Helge Deller <deller@xxxxxx>
Cc: Thomas Zimmermann <tzimmermann@xxxxxxx>
Cc: Christophe Leroy <christophe.leroy@xxxxxxxxxx>
Cc: linux-fbdev@xxxxxxxxxxxxxxx
Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx
Reviewed-by: Luis Chamberlain <mcgrof@xxxxxxxxxx>
Is anyone using this driver these days? How often do fbdev drivers get
audited to see what can be nuked?
Geert already mentioned that this one is likely used on old
powermac systems.
and the latest generation of parisc machines use it too.
In addition, on parisc machines it's also important to map all io-space
memory uncacheable. Since ioremap() takes care of it anyway, the ioremap_uc()
was simply referencing the call to ioremap().
Helge
I think my arm boardfile removal orphaned
some other fbdev drivers though. I removed the ones that can
no longer be enabled, but think a bunch of other ones
are still selectable but have no platform_device definition
or DT support: FB_PXA168, FB_DA8XX, FB_MX3, and MMP_FB.
These four platforms are all still supported with DT, but
over time it gets less likely that anyone is still interested
in adding DT support to the fbdev drivers.
Arnd
