fix this warning:
WARNING: at drivers/gpio/gpiolib.c:101 gpio_ensure_requested+0x48/0x114()
autorequest GPIO-331
[<c043b170>] (unwind_backtrace+0x0/0xf0) from [<c0461800>] (warn_slowpath_common+0x4c/0x64)
[<c0461800>] (warn_slowpath_common+0x4c/0x64) from [<c0461898>] (warn_slowpath_fmt+0x2c/0x3c)
[<c0461898>] (warn_slowpath_fmt+0x2c/0x3c) from [<c05bb514>] (gpio_ensure_requested+0x48/0x114)
[<c05bb514>] (gpio_ensure_requested+0x48/0x114) from [<c05bbbb4>] (gpio_direction_output+0x7c/0xfc)
[<c05bbbb4>] (gpio_direction_output+0x7c/0xfc) from [<c044ccf8>] (rk29_backlight_pwm_suspend+0x54/0x74)
[<c044ccf8>] (rk29_backlight_pwm_suspend+0x54/0x74) from [<c05c3d0c>] (rk29_bl_suspend+0x78/0x90)
[<c05c3d0c>] (rk29_bl_suspend+0x78/0x90) from [<c0494374>] (early_suspend+0xc4/0x12c)
[<c0494374>] (early_suspend+0xc4/0x12c) from [<c04745c4>] (process_one_work+0x250/0x3ac)
[<c04745c4>] (process_one_work+0x250/0x3ac) from [<c0474b08>] (worker_thread+0x22c/0x3ec)
[<c0474b08>] (worker_thread+0x22c/0x3ec) from [<c047a484>] (kthread+0x80/0x88)
[<c047a484>] (kthread+0x80/0x88) from [<c04365f8>] (kernel_thread_exit+0x0/0x8)
fix this bug:
rk30_pm_power_off start...
Unable to handle kernel NULL pointer dereference at virtual address 00000054
pgd = c0404000
[00000054] *pgd=00000000pre WM831X_POWER_STATE = 0x8800
wm831x_last_deinit
Internal error: Oops: 17 [#1] PREEMPT SMP
CPU: 0 Tainted: G C (3.0.8+ #2)
PC is at rkfb_early_suspend+0x18/0x70
LR is at early_suspend+0xc4/0x12c
commit e787ec1376 upstream.
The inline assembly in kernel_execve() uses r8 and r9. Since this
code sequence does not return, it usually doesn't matter if the
register clobber list is accurate. However, I saw a case where a
particular version of gcc used r8 as an intermediate for the value
eventually passed to r9. Because r8 is used in the inline
assembly, and not mentioned in the clobber list, r9 was set
to an incorrect value.
This resulted in a kernel panic on execution of the first user-space
program in the system. r9 is used in ret_to_user as the thread_info
pointer, and if it's wrong, bad things happen.
Signed-off-by: Tim Bird <tim.bird@am.sony.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6a1c53124a upstream.
TPIDRURW is a user read/write register forming part of the group of
thread registers in more recent versions of the ARM architecture (~v6+).
Currently, the kernel does not touch this register, which allows tasks
to communicate covertly by reading and writing to the register without
context-switching affecting its contents.
This patch clears TPIDRURW when TPIDRURO is updated via the set_tls
macro, which is called directly from __switch_to. Since the current
behaviour makes the register useless to userspace as far as thread
pointers are concerned, simply clearing the register (rather than saving
and restoring it) will not cause any problems to userspace.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 078c04545b upstream.
Currently when ThumbEE is not enabled (!CONFIG_ARM_THUMBEE) the ThumbEE
register states are not saved/restored at context switch. The default state
of the ThumbEE Ctrl register (TEECR) allows userspace accesses to the
ThumbEE Base Handler register (TEEHBR). This can cause unexpected behaviour
when people use ThumbEE on !CONFIG_ARM_THUMBEE kernels, as well as allowing
covert communication - eg between userspace tasks running inside chroot
jails.
This patch sets up TEECR in order to prevent user-space access to TEEHBR
when !CONFIG_ARM_THUMBEE. In this case, tasks are sent SIGILL if they try to
access TEEHBR.
Reviewed-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Jonathan Austin <jonathan.austin@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
