staging: fbtft: force cast to non-__iomem pointer
Subsystems (2)
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 *addrdrivers/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
@@ -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
Greg Kroah-Hartman
maintainerQuoted 3 lines · Garret Kelly
fbtft uses fb_info's
screen_basefield to store a non-__iomem allocation. Cast away the__iomemqualifier 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
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
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_basepointer insidefb_infothat isn't__iomem? There are already a bunch of framebuffer drivers that (ab)usescreen_baseto 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