diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c b/drivers/staging/fbtft/fb_agm1264k-fl.c
index 9cc7d25..9114239 100644
--- a/drivers/staging/fbtft/fb_agm1264k-fl.c
+++ b/drivers/staging/fbtft/fb_agm1264k-fl.c
@@ -273,7 +273,7 @@ construct_line_bitmap(struct fbtft_par *par, u8 *dest, signed short *src,
static int write_vmem(struct fbtft_par *par, size_t offset, size_t len)
{
- u16 *vmem16 = (u16 *)par->info->screen_base;
+ u16 __iomem *vmem16 = (u16 __iomem *)par->info->screen_base;
I haven't looked. What is the type for ->screen_base and why can't it
be declared as __iomem type?
http://lxr.free-electrons.com/source/include/linux/fb.h#L486
screen_base is component of struct fb_info, defined as "char __iomem *".
In drivers/staging/fbtft/fbtft-core.c, it looks to be actually set to
a pointer resulting from vzalloc().
Hm, you're right. Normally, it's an __iomem * but this time it's not
an __iomem pointer. Adding anotations to mark it as __iomem is wrong
and adding calls to ioread16() is buggy.
There are a couple ways to make these warnings go away. The simplest
is just to silence the warning with __force:
u16 *vmem16 = (u16 __force *)par->info->screen_base;
This is how some fbdev drivers with vmalloc'ed memory does this:
video/fbdev/{metronomefb.c,hecubafb.c}:
unsigned char *buf = (unsigned char __force *)par->info->screen_base;
info->screen_base = (char __force __iomem *)videomemory;
drivers/video/fbdev/ssd1307fb.c (this one is quite new: 3.15):
u8 __iomem *dst; dst = (void __force *) (info->screen_base + p);
info->screen_base = (u8 __force __iomem *)vmem;
We have to use screen_base because of vmalloc'ed memory and deferred io
(fb_deferred_io_page).
I'm not terribly familiar with this code. I don't know that this is the
cleanest approach. We could also just leave the code alone for now and
ignore the warning.
Yes, it's best to leave this alone for now.
I'm working on a proposal to provide better layering and minimal coupling
to fbdev. This will hopefully lead to screen_base eventually being used
only twice in the fbtft module and nowhere else.
Regards,
Noralf Trønnes
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
