From: Alan Curry Date: Mon, 27 Mar 2006 09:17:30 +0000 (-0800) Subject: [PATCH] framebuffer: cmap-setting return values X-Git-Url: https://git.stricted.de/?a=commitdiff_plain;h=db77ec270d00098ff4fbf15f62f4506f6efb25d2;p=GitHub%2FLineageOS%2Fandroid_kernel_motorola_exynos9610.git [PATCH] framebuffer: cmap-setting return values A set of 3 small bugfixes, all of which are related to bogus return values of fb colormap-setting functions. First, fb_alloc_cmap returns -1 if memory allocation fails. This is a hard condition to reproduce since you'd have to be really low on memory, but from studying the contexts in which it is called, I think this function should be returning a negative errno, and the -1 will be seen as an EPERM. Switching it to -ENOMEM makes sense. Second, the store_cmap function which is called for writes to /sys/class/graphics/fb0/color_map returns 0 for success, but it should be returning the count of bytes written since its return value ends up in userspace as the result of the write() syscall. Third, radeonfb returns 1 instead of a negative errno when FBIOPUTCMAP is called with an oversized colormap. This is seen in userspace as a return value of 1 from the ioctl() syscall with errno left unchanged. A more useful return value would be -EINVAL. Signed-off-by: Alan Curry Cc: "Antonino A. Daplas" Cc: Benjamin Herrenschmidt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- diff --git a/drivers/video/aty/radeon_base.c b/drivers/video/aty/radeon_base.c index c9f0c5a07e6e..9a6b5b39b88e 100644 --- a/drivers/video/aty/radeon_base.c +++ b/drivers/video/aty/radeon_base.c @@ -1067,7 +1067,7 @@ static int radeon_setcolreg (unsigned regno, unsigned red, unsigned green, if (regno > 255) - return 1; + return -EINVAL; red >>= 8; green >>= 8; @@ -1086,9 +1086,9 @@ static int radeon_setcolreg (unsigned regno, unsigned red, unsigned green, pindex = regno * 8; if (rinfo->depth == 16 && regno > 63) - return 1; + return -EINVAL; if (rinfo->depth == 15 && regno > 31) - return 1; + return -EINVAL; /* For 565, the green component is mixed one order * below diff --git a/drivers/video/fbcmap.c b/drivers/video/fbcmap.c index c32a2a50bfa2..1f98392a43b3 100644 --- a/drivers/video/fbcmap.c +++ b/drivers/video/fbcmap.c @@ -85,7 +85,7 @@ static struct fb_cmap default_16_colors = { * Allocates memory for a colormap @cmap. @len is the * number of entries in the palette. * - * Returns -1 errno on error, or zero on success. + * Returns negative errno on error, or zero on success. * */ @@ -116,7 +116,7 @@ int fb_alloc_cmap(struct fb_cmap *cmap, int len, int transp) fail: fb_dealloc_cmap(cmap); - return -1; + return -ENOMEM; } /** diff --git a/drivers/video/fbsysfs.c b/drivers/video/fbsysfs.c index 6d26057337e2..b72b05250a9d 100644 --- a/drivers/video/fbsysfs.c +++ b/drivers/video/fbsysfs.c @@ -348,7 +348,7 @@ static ssize_t store_cmap(struct class_device *class_device, const char *buf, fb_copy_cmap(&umap, &fb_info->cmap); fb_dealloc_cmap(&umap); - return rc; + return rc ?: count; } for (i = 0; i < length; i++) { u16 red, blue, green, tsp; @@ -367,7 +367,7 @@ static ssize_t store_cmap(struct class_device *class_device, const char *buf, if (transp) fb_info->cmap.transp[i] = tsp; } - return 0; + return count; } static ssize_t show_cmap(struct class_device *class_device, char *buf)