linux-toradex.git/drivers/video/console/fbcon.c, branch v4.4.64

fbcon: Fix vc attr at deinit

2017-03-30T07:35:20+00:00

commit 8aac7f34369726d1a158788ae8aff3002d5eb528 upstream.

fbcon can deal with vc_hi_font_mask (the upper 256 chars) and adjust
the vc attrs dynamically when vc_hi_font_mask is changed at
fbcon_init().  When the vc_hi_font_mask is set, it remaps the attrs in
the existing console buffer with one bit shift up (for 9 bits), while
it remaps with one bit shift down (for 8 bits) when the value is
cleared.  It works fine as long as the font gets updated after fbcon
was initialized.

However, we hit a bizarre problem when the console is switched to
another fb driver (typically from vesafb or efifb to drmfb).  At
switching to the new fb driver, we temporarily rebind the console to
the dummy console, then rebind to the new driver.  During the
switching, we leave the modified attrs as is.  Thus, the new fbcon
takes over the old buffer as if it were to contain 8 bits chars
(although the attrs are still shifted for 9 bits), and effectively
this results in the yellow color texts instead of the original white
color, as found in the bugzilla entry below.

An easy fix for this is to re-adjust the attrs before leaving the
fbcon at con_deinit callback.  Since the code to adjust the attrs is
already present in the current fbcon code, in this patch, we simply
factor out the relevant code, and call it from fbcon_deinit().

Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1000619
Signed-off-by: Takashi Iwai 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Cc: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

fbcon: set a default value to blink interval

2016-03-09T23:34:50+00:00

commit a1e533ec07d583d01349ef13c0c965b8633e1b91 upstream.

Since commit 27a4c827c34ac4256a190cc9d24607f953c1c459
	fbcon: use the cursor blink interval provided by vt

two attempts have been made at fixing a possible hang caused by
cursor_timer_handler. That function registers a timer to be triggered at
"jiffies + fbcon_ops.cur_blink_jiffies".

A new case had been encountered during initialisation of clcd-pl11x:

    fbcon_fb_registered
    do_fbcon_takeover

    ->  do_register_con_driver
        fbcon_startup
    (A) add_cursor_timer (with cur_blink_jiffies = 0)

    ->  do_bind_con_driver
        visual_init
        fbcon_init
    (B) cur_blink_jiffies = msecs_to_jiffies(vc->vc_cur_blink_ms);

If we take an softirq anywhere between A and B (and we do),
cursor_timer_handler executes indefinitely.

Instead of patching all possible paths that lead to this case one at a
time, fix the issue at the source and initialise cur_blink_jiffies to
200ms when allocating fbcon_ops. This was its default value before
aforesaid commit. fbcon_cursor or fbcon_init will refine this value
downstream.

Signed-off-by: Jean-Philippe Brucker 
Tested-by: Scot Doyle 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Greg Kroah-Hartman

fbcon: initialize blink interval before calling fb_set_par

2015-10-18T05:00:39+00:00

Since commit 27a4c827c34ac4256a190cc9d24607f953c1c459
    fbcon: use the cursor blink interval provided by vt

a PPC64LE kernel fails to boot when fbcon_add_cursor_timer uses an
uninitialized ops->cur_blink_jiffies. Prevent by initializing
in fbcon_init before the call to info->fbops->fb_set_par.

Reported-and-tested-by: Alistair Popple 
Signed-off-by: Scot Doyle 
Cc:  [v4.2]
Signed-off-by: Greg Kroah-Hartman

fbcon: unconditionally initialize cursor blink interval

2015-08-10T14:20:32+00:00

A sun7i-a20-olinuxino-micro fails to boot when kernel parameter
vt.global_cursor_default=0. The value is copied to vc->vc_deccm
causing the initialization of ops->cur_blink_jiffies to be skipped.
Unconditionally initialize it.

Reported-and-tested-by: Jonathan Liu 
Signed-off-by: Scot Doyle 
Acked-by: Pavel Machek 
Signed-off-by: Tomi Valkeinen

fbcon: Avoid deleting a timer in IRQ context

2015-05-27T12:55:38+00:00

Commit 27a4c827c34a ("fbcon: use the cursor blink interval provided by
vt") unconditionally removes the cursor blink timer. Unfortunately that
wreaks havoc under some circumstances. An easily reproducible way is to
use both the framebuffer console and a debug serial port as the console
output for kernel messages (e.g. "console=ttyS0 console=tty1" on the
kernel command-line. Upon boot this triggers a warning from within the
del_timer_sync() function because it is called from IRQ context:

	[    5.070096] ------------[ cut here ]------------
	[    5.070110] WARNING: CPU: 0 PID: 0 at ../kernel/time/timer.c:1098 del_timer_sync+0x4c/0x54()
	[    5.070115] Modules linked in:
	[    5.070120] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.0-rc4-next-20150519 #1
	[    5.070123] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
	[    5.070142] [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
	[    5.070156] [] (show_stack) from [] (dump_stack+0x70/0xbc)
	[    5.070164] [] (dump_stack) from [] (warn_slowpath_common+0x74/0xb0)
	[    5.070169] [] (warn_slowpath_common) from [] (warn_slowpath_null+0x1c/0x24)
	[    5.070174] [] (warn_slowpath_null) from [] (del_timer_sync+0x4c/0x54)
	[    5.070183] [] (del_timer_sync) from [] (fbcon_del_cursor_timer+0x2c/0x40)
	[    5.070190] [] (fbcon_del_cursor_timer) from [] (fbcon_cursor+0x9c/0x180)
	[    5.070198] [] (fbcon_cursor) from [] (hide_cursor+0x30/0x98)
	[    5.070204] [] (hide_cursor) from [] (vt_console_print+0x2a8/0x340)
	[    5.070212] [] (vt_console_print) from [] (call_console_drivers.constprop.23+0xc8/0xec)
	[    5.070218] [] (call_console_drivers.constprop.23) from [] (console_unlock+0x498/0x4f0)
	[    5.070223] [] (console_unlock) from [] (vprintk_emit+0x1f0/0x508)
	[    5.070228] [] (vprintk_emit) from [] (vprintk_default+0x24/0x2c)
	[    5.070234] [] (vprintk_default) from [] (printk+0x70/0x88)

After which the system starts spewing all kinds of weird and seemingly
unrelated error messages.

This commit fixes this by restoring the condition under which the call
to fbcon_del_cursor_timer() happens.

Reported-by: Daniel Stone 
Reported-by: Kevin Hilman 
Tested-by: Kevin Hilman 
Tested-by: Scot Doyle 
Signed-off-by: Thierry Reding 
Tested-by: Andrew Vagin 
Tested-by: Tomeu Vizoso 
Signed-off-by: Greg Kroah-Hartman

fbcon: use the cursor blink interval provided by vt

2015-05-10T17:15:52+00:00

vt now provides a cursor blink interval via vc_data. Use this
interval instead of the currently hardcoded 200 msecs. Store it in
fbcon_ops to avoid locking the console in cursor_timer_handler().

Signed-off-by: Scot Doyle 
Acked-by: Pavel Machek 
Signed-off-by: Greg Kroah-Hartman

fbcon: Remove unused vblank cursor code

2015-01-26T12:10:37+00:00

commit 1fa0b29f3a43 ("fbdev: Kill Atari vblank cursor blinking")

rendered vbl_cursor_cnt and therefore CURSOR_DRAW_DELAY unused in fbcon.c,
so remove them.

Signed-off-by: Scot Doyle 
Signed-off-by: Tomi Valkeinen

fbcon: Change fbcon_init from module_init to fs_initcall

2014-11-14T13:29:11+00:00

Various fb drivers register themselves before module_init so as to have a
console as early as possible, this is of little use if fbcon does not
initialize early too.

Fbcon cannot initialize earlier then fs_initcall, because then the creation
of /sys/class/graphics/fbcon will fail.

Signed-off-by: Hans de Goede 
Signed-off-by: Tomi Valkeinen

fbcon: Fix option parsing control flow in fb_console_setup

2014-10-22T06:49:40+00:00

Since strsep is used to tokenize the options string, after each option
match the code should use "continue" to get the next token from strsep.
This patch applies this pattern consistently.

Previously, for "scrollback:" and "map:" the parse code would return
(unconditionally: strsep ensures *options != ','), causing any
following option to be ignored, while for "vc:" the parse code would
go on to parse further options within the same token, which could lead
to invalid input being accepted.

Signed-off-by: Maarten ter Huurne 
Acked-by: Paul Cercueil 
Signed-off-by: Tomi Valkeinen

fbcon: Fix memory leak in con2fb_release_oldinfo()

2014-05-09T09:55:49+00:00

kmemleak reported a memory leak as below.

unreferenced object 0xffff8800dab6d8d8 (size 96):
  comm "swapper/0", pid 1, jiffies 4294877598 (age 38.483s)
  hex dump (first 32 bytes):
    00 00 00 00 00 01 00 00 08 00 00 00 10 00 00 00  ................
    07 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00  ................
  backtrace:
    [] kmemleak_alloc+0x4e/0xb0
    [] __kmalloc+0x280/0x320
    [] soft_cursor+0x231/0x290
    [] bit_cursor+0x613/0x650
    [] fbcon_cursor+0x13b/0x1c0
    [] hide_cursor+0x28/0xa0
    [] redraw_screen+0x168/0x240
    [] fbcon_prepare_logo+0x381/0x420
    [] fbcon_init+0x34e/0x590
    [] visual_init+0xb8/0x120
    [] do_bind_con_driver+0x163/0x380
    [] do_take_over_console+0x114/0x1c0
    [] do_fbcon_takeover+0x63/0xd0
    [] fbcon_event_notify+0x68d/0x7e0
    [] notifier_call_chain+0x4c/0x70
    [] __blocking_notifier_call_chain+0x4d/0x70

This memory leak cause is, fbcon_ops's cursor_src is allocated in
soft_cursor() but not released in con2fb_release_oldinfo().
so, cursor_src is needed to be released when oldinfo is going to be
released.

Signed-off-by: Masami Ichikawa 
Signed-off-by: Tomi Valkeinen