Skip to contentSkip to conversation

staging: fbtft: force cast to non-__iomem pointer

PATCH In review Garret Kelly 3 participants 4 messages Apr 16, 2015 – May 7, 2015

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 staging: fbtft: force cast to non-__iomem pointer

fbtft uses fb_info's screen_base field to store a non-__iomem allocation. Cast away the __iomem qualifier when freeing the pointer to suppress the sparse warning.

Fixes the following sparse warnings:
drivers/staging/fbtft/fbtft-core.c:918:19: warning: incorrect type in argument 1 (different address spaces)
drivers/staging/fbtft/fbtft-core.c:918:19: expected void const *addr
drivers/staging/fbtft/fbtft-core.c:918:19: got char [noderef] <asn:2>*screen_base

---
 drivers/staging/fbtft/fbtft-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/staging/fbtft/fbtft-core.c +1 -1
index 37dcf7e..1196dda 100644
@@ -925,7 +925,7 @@ EXPORT_SYMBOL(fbtft_framebuffer_alloc);
 void fbtft_framebuffer_release(struct fb_info *info)
 {
 	fb_deferred_io_cleanup(info);
-	vfree(info->screen_base);
+	vfree((void __force *)info->screen_base);
 	framebuffer_release(info);
 }
 EXPORT_SYMBOL(fbtft_framebuffer_release);
Signature · 1 line
2.0.2
#1 lore raw
Quoted 3 lines · Garret Kelly

fbtft uses fb_info's screen_base field to store a non-__iomem allocation. Cast away the __iomem qualifier when freeing the pointer to suppress the sparse warning.

Can't we fix this properly, to use the correct type of pointer instead for non-__iomem allocations?

thanks,

greg k-h

#2 lore raw
Quoted 2 lines

Can't we fix this properly, to use the correct type of pointer instead for non-__iomem allocations?

You mean making an alternate screen_base pointer inside fb_info that isn't __iomem? There are already a bunch of framebuffer drivers that (ab)use screen_base to store non-__iomem pointers, so this didn't strike me as too far out of line.

Garret

#3 lore raw
Quoted 7 lines · Garret Kelly
Quoted 2 lines

Can't we fix this properly, to use the correct type of pointer instead for non-__iomem allocations?

You mean making an alternate screen_base pointer inside fb_info that isn't __iomem? There are already a bunch of framebuffer drivers that (ab)use screen_base to store non-__iomem pointers, so this didn't strike me as too far out of line.

You could add a new pointer or you could just make ->screen_base a union. I'm not sure which is the best.

regards,
dan carpenter