diff options
author | Alan Curry <pacman@TheWorld.com> | 2006-03-27 01:17:30 -0800 |
---|---|---|
committer | Linus Torvalds <torvalds@g5.osdl.org> | 2006-03-27 08:44:56 -0800 |
commit | db77ec270d00098ff4fbf15f62f4506f6efb25d2 (patch) | |
tree | c4d49f61e120624d435b80b9ee7448eb6f064046 /Makefile | |
parent | 59153f7d7effdb5b3c81eb6d03914a866157b319 (diff) |
[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 <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>
Diffstat (limited to 'Makefile')
0 files changed, 0 insertions, 0 deletions