summaryrefslogtreecommitdiffstats
path: root/drivers/video/fbcmap.c
Commit message (Collapse)AuthorAgeFilesLines
* drivers: video: fbcmap: remove the redundency and incorrect checkingsChen Gang2013-08-301-6/+1
| | | | | | | | | | | | fb_set_cmap() already checks the parameters, so need remove the redundancy checking. This redundancy checking is also incorrect, the related warning: drivers/video/fbcmap.c:288:2: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits] Signed-off-by: Chen Gang <gang.chen@asianux.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* framebuffer: fix fbcmap.c kernel-doc warningRandy Dunlap2010-11-261-0/+1
| | | | | | | | | Fix kernel-doc warning in fbcmap.c: Warning(drivers/video/fbcmap.c:92): No description found for parameter 'flags' Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
* fbcmap: integer overflow bugDan Carpenter2010-11-171-8/+20
| | | | | | | | | | | | | | | | | | | | | | | | There is an integer overflow in fb_set_user_cmap() because cmap->len * 2 can wrap. It's basically harmless. Your terminal will be messed up until you type reset. This patch does three things to fix the bug. First, it checks the return value of fb_copy_cmap() in fb_alloc_cmap(). That is enough to fix address the overflow. Second it checks for the integer overflow in fb_set_user_cmap(). Lastly I wanted to cap "cmap->len" in fb_set_user_cmap() much lower because it gets used to determine the size of allocation. Unfortunately no one knows what the limit should be. Instead what this patch does is makes the allocation happen with GFP_KERNEL instead of GFP_ATOMIC and lets the kmalloc() decide what values of cmap->len are reasonable. To do this, the patch introduces a function called fb_alloc_cmap_gfp() which is like fb_alloc_cmap() except that it takes a GFP flag. Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
* fbcmap: cleanup white space in fb_alloc_cmap()Dan Carpenter2010-11-171-24/+30
| | | | | | | | checkpatch.pl and Andrew Morton both complained about the indenting in fb_alloc_cmap() Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
* fbmem: don't call copy_from/to_user() with mutex heldAndrea Righi2009-02-051-6/+14
| | | | | | | | | | | | | | | | | | | | | | | Avoid calling copy_from/to_user() with fb_info->lock mutex held in fbmem ioctl(). fb_mmap() is called under mm->mmap_sem (A) held, that also acquires fb_info->lock (B); fb_ioctl() takes fb_info->lock (B) and does copy_from/to_user() that might acquire mm->mmap_sem (A), causing a deadlock. NOTE: it doesn't push down the fb_info->lock in each own driver's fb_ioctl(), so there are still potential deadlocks elsewhere. Signed-off-by: Andrea Righi <righi.andrea@gmail.com> Cc: Dave Jones <davej@redhat.com> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Johannes Weiner <hannes@saeurebad.de> Cc: Krzysztof Helt <krzysztof.h1@wp.pl> Cc: Harvey Harrison <harvey.harrison@gmail.com> Cc: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* fbdev: change asm/uaccess.h to linux/uaccess.hKrzysztof Helt2007-10-161-2/+1
| | | | | | | | | | | This patch replaces <asm/uaccess.h> with <linux/uaccess.h> after the checkpatch.pl hint. The include of <asm/uaccess.h> is removed if the driver does not use it. Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl> Signed-off-by: Antonino Daplas <adaplas@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [PATCH] fbcmap.c: mark structs const or __read_mostlyHelge Deller2006-12-081-27/+28
| | | | | | | | | | | | | | | | - Mark the default colormaps read-only, as nobody should be allowed to modify them - Additionally mark color values as __read_mostly since they will only be modified (very seldom) by fb_invert_cmaps() - Add named C99-initializers in fb_cmap structs and use the ARRAY_SIZE() macro Signed-off-by: Helge Deller <deller@gmx.de> Acked-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] vt: Remove VT-specific declarations and definitions from tty.hJon Smirl2006-07-101-1/+0
| | | | | | | | | | | | | MAX_NR_CONSOLES, fg_console, want_console and last_console are more of a function of the VT layer than the TTY one. Moving these to vt.h and vt_kern.h allows all of the framebuffer and VT console drivers to remove their dependency on tty.h. [akpm@osdl.org: fix alpha build] Signed-off-by: Jon Smirl <jonsmir@gmail.com> Signed-off-by: Antonino Daplas <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] framebuffer: cmap-setting return valuesAlan Curry2006-03-271-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* [PATCH] fbdev: update info->cmap when setting cmap from user-/kernelspace.Michal Januszewski2005-07-271-60/+36
| | | | | | | | | | | | | | | | | | | | | | The fb_info struct, as defined in include/linux/fb.h, contains an element that is supposed to hold the current color map: struct fb_cmap cmap; /* Current cmap */ This cmap is currently never updated when either fb_set_cmap() or fb_set_user_cmap() are called. As a result, info->cmap contains the default cmap that was set by a device driver/fbcon and a userspace application using the FBIOGETCMAP ioctl will not always get the *currently* used color map. The patch fixes this by making sure the cmap is copied to info->cmap after it is set correctly. It moves most of the code that is responsible for setting the cmap to fb_set_cmap() and out of fb_set_user_cmap() to avoid code-duplication. Signed-off-by: Michal Januszewski <spock@gentoo.org> Cc: <linux-fbdev-devel@lists.sourceforge.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] fbdev: Batch cmap changes at driver levelBenjamin Herrenschmidt2005-05-011-2/+30
| | | | | | | | | | | This patch adds to the fbdev interface a set_cmap callback that allow the driver to "batch" palette changes. This is useful for drivers like radeonfb which might require lenghtly workarounds on palette accesses, thus allowing to factor out those workarounds efficiently. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-161-0/+337
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
OpenPOWER on IntegriCloud