forked from luck/tmp_suning_uos_patched
db77ec270d
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 <pacman@TheWorld.com> Cc: "Antonino A. Daplas" <adaplas@pol.net> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> |
||
---|---|---|
.. | ||
ati_ids.h | ||
aty128fb.c | ||
atyfb_base.c | ||
atyfb.h | ||
mach64_accel.c | ||
mach64_ct.c | ||
mach64_cursor.c | ||
mach64_gx.c | ||
Makefile | ||
radeon_accel.c | ||
radeon_base.c | ||
radeon_i2c.c | ||
radeon_monitor.c | ||
radeon_pm.c | ||
radeonfb.h |