ARM: tizen_odroid_defconfig: enable mali400 r5p2_rel0

Enable mali400 r5p2_rel0 instead of r4p0_rel0.

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

ARM: tizen_odroid_defconfig: enable mali midgard r12p0_04rel0

We will use mali midgard r12p0_04rel0 instead of r5p0_06rel0.

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

ARM64: tizen_tm2_defconfig: enable mali midgard r12p0_04rel0

We will use mali midgard r12p0_04rel0 instead of r5p0_06rel0.

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

ARM: mali400: r5p2_rel0: use get_unused_fd_flags(O_CLOEXEC) instead of get_unused_fd()

get_unused_fd() was changed to get_unused_fd_flags() by the commit
1a7bd2265fc5 ("make get_unused_fd_flags() a function"), so it causes
build error,

drivers/gpu/arm/mali400/r5p2_rel0/linux/mali_sync.c: In function 'mali_sync_fence_fd_alloc':
drivers/gpu/arm/mali400/r5p2_rel0/linux/mali_sync.c:235:2: error: implicit declaration of function 'get_unused_fd' [-Werror=implicit-function-declaration]
  fd = get_unused_fd();
  ^

This patch was refered from the commit 45acea57335e ("android/sw_sync:
use get_unused_fd_flags(O_CLOEXEC) instead of get_unused_fd()")

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

ARM: mali400: r5p2_rel0: replace CONFIG_PM_RUNTIME to CONFIG_PM

After commit 464ed18ebdb6 ("PM: Eliminate CONFIG_PM_RUNTIME") which
is applied kernel version 3.19, PM_RUNTIME is eliminated. So this
patch replaces CONFIG_PM_RUNTIME to CONFIG_PM for kernel version
larger than 3.19.

Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
[jy0922.shim: apply to mali400 r5p2_rel0 with some modification]
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

ARM: mali400: r5p2_rel0: fix build error

Include pm_runtime.h to fix below build error when CONFIG_PM_RUNTIME is
disabled.

drivers/gpu/arm/mali400/r5p2_rel0/linux/mali_kernel_linux.c: In function ‘mali_driver_suspend_scheduler’:
drivers/gpu/arm/mali400/r5p2_rel0/linux/mali_kernel_linux.c:595:2: error: implicit declaration of function ‘pm_runtime_active’ [-Werror=implicit-function-declaration]
  if (pm_runtime_active(dev))
  ^

Change-Id: Ic613dd9785a9d563e50361328944bd23d33fd70c
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

ARM: mali400: fix building out of tree

s/$(src)/$(srctree)\/$(src)/

$(srctree) has absolute path of kernel root directory, so with this
commit, building problem by relative path will be gone from outside of
kernel tree.

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

ARM: mali400: r5p2_rel0: add GLES mem profiler feature

This patch adds GLES mem profiler feature.

You could use it by "cat /sys/kernel/debug/mali/gles_mem/<PID>".
Without user-DDK's MALI_IOC_MEM_PROFILE_GLES_MEM, it only show layout.

With this ioctl, you could check current GLES relevant memory status
in opened session and also check memory leakage in trash subdirectory.

The mechanism of detecting memory leakage is checking information when
the session is closed. So the user misses to free (GLES)memory during
session, it(the PID) could be found in trash.

Caution! When app is killed and the session is forcely shut down, then
it(the PID) could be found in trash but we can not guarantee there is a
real memory leakage. That is because like this case, it is impossible
to call MALI_IOC_MEM_PROFILE_GLES_MEM to remove allocated memory.

Change-Id: I78a08f7b53594dc20f8cc6f4c892250fdc9e8208
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
[jy0922.shim: applied to r5p2_rel0 from r5p0_rel0]
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

ARM: mali400: r5p2_rel0: delete proprietary word in Kbuild

This is to guid for non-gpl case, not related with license,
but Tango detects it because it simply compares string.

Change-Id: Iad42e139fd5d040b3242f1e7358720ef24343570
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com>
[jy0922.shim: applied to r5p2_rel0 from r5p0_rel0]
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

ARM: mali400: r5p2_rel0: fix of_match_table

The exynos platform of this kernel has exynos specific of_match_table,
so use mali_of_matches of exynos instead of base_dt_ids of mali.

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

ARM: mali400: r5p2_rel0: fix for exynos

The exynos platform codes have to be modified a bit to apply
r5p2_rel0. If not, will occurs build errors.

  CC      drivers/gpu/arm/mali400/r5p2_rel0/linux/mali_kernel_linux.o
drivers/gpu/arm/mali400/r5p2_rel0/linux/mali_kernel_linux.c:190:13: error: conflicting types for ‘mali_platform_power_mode_change’
 extern void mali_platform_power_mode_change(int power_mode);
...
drivers/gpu/arm/mali400/r5p2_rel0/platform/exynos/exynos.c:246:2: error: unknown field ‘utilization_interval’ specified in initializer
  .utilization_interval = 100, /* 100ms in Tizen */
  ^
...
drivers/built-in.o: In function `mali_remove':
/home/pub/git/spin/linux-exynos/drivers/gpu/arm/mali400/r5p2_rel0/linux/mali_kernel_linux.c:561: undefined reference to `mali_platform_device_deinit'
drivers/built-in.o: In function `mali_probe':
/home/pub/git/spin/linux-exynos/drivers/gpu/arm/mali400/r5p2_rel0/linux/mali_kernel_linux.c:515: undefined reference to `mali_platform_device_init'
drivers/built-in.o: In function `mali_hw_core_register_read':
/home/pub/git/spin/linux-exynos/drivers/gpu/arm/mali400/r5p2_rel0/common/mali_hw_core.h:52: undefined reference to `mali_is_on'
drivers/built-in.o: In function `mali_hw_core_register_write':
/home/pub/git/spin/linux-exynos/drivers/gpu/arm/mali400/r5p2_rel0/common/mali_hw_core.h:98: undefined reference to `mali_is_on'
drivers/built-in.o: In function `mali_hw_core_register_read':
/home/pub/git/spin/linux-exynos/drivers/gpu/arm/mali400/r5p2_rel0/common/mali_hw_core.h:52: undefined reference to `mali_is_on'
/home/pub/git/spin/linux-exynos/drivers/gpu/arm/mali400/r5p2_rel0/common/mali_hw_core.h:52: undefined reference to `mali_is_on'
drivers/built-in.o: In function `mali_hw_core_register_write':
/home/pub/git/spin/linux-exynos/drivers/gpu/arm/mali400/r5p2_rel0/common/mali_hw_core.h:98: undefined reference to `mali_is_on'
drivers/built-in.o:/home/pub/git/spin/linux-exynos/drivers/gpu/arm/mali400/r5p2_rel0/common/mali_hw_core.h:52: more undefined references to `mali_is_on' follow

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

ARM: mali400: r5p2_rel0: add exynos platform codes

This comes from r4p0_rel0.

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

ARM: mali400: r5p2_rel0: sync codes for TM1 from r5p0_rel0

Spectrum added some codes on r5p0_rel0 public, so do it on r5p2_rel0.
But except some codes related with below defines

SPRD_MEM_OPT_PAGE_TABLE_SHRINK
MALI_IOC_MEM_INIT
MALI_IOC_MEM_TERM

because we cannot add them by changed codes from r5p2_rel0.

Change-Id: I1423e7ce5181d4f1a08f3fbd01f9d426290eff29
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

ARM: mali400: r5p2_rel0: fix Makefile & Kconfig

For building of r5p2_rel0.

Change-Id: I23c3144d886b9cbfe6061650ab16d180eb74e94c
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

ARM: mali400: r5p2_rel0: add public codes from ARM

This comes from DX910-SW-99002-r5p2-00rel0.tgz of ARM web site.

Change-Id: I8d556f4abba5497679068eec6540a1d7716f6ebb
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

ARM: mali400: r4p0_rel0: fix to rearrange resources

Above commit ("ARM: dts: exynos4x12: fix g3d nodes") changes order of
reg resources, so need to fix codes to rearrange resources.

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

ARM: dts: exynos4x12: fix g3d nodes

This fixes order of reg resources. First has to be resource that has
lowest address because mali400 r5p2 version requires it.

This also adds interrupt-names for g3d nodes. The interrupt-names needs
at mali400 r5p2 version.

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

ARM: dts: exynos5422-odroidxu3-common: Add mali regulator supply

mali-supply is used for devfreq voltage supply control.

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

ARM64: dts: exynos5433: Add power_nodel node for mali midgard

Property values taken from example for Mali-T602 from
Documentation/devicetree/bindings/arm/mali-midgard.txt.

Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>

ARM64: dts: exynos5433-tm2e: Add mali regulator supply

mali-supply is used for devfreq voltage supply control.

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

ARM64: dts: exynos5433-tm2: Add mali regulator supply

mali-supply is used for devfreq voltage supply control.

Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
[jy0922.shim: apply to dts of tm2]
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

Documentation: Add devicetree bindings documentation for Mali Midgard

Extracted from TX011-BU-00001-r10p0-00rel0.tgz downloaded from
malideveloper.arm.com.

Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>

gpu: arm: midgard: r12p0_04rel0: add exynos5422 platform files

This is based on exynos5433 platform files.

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

gpu: arm: midgard: r12p0_04rel0: Fix incorrect IS_ERR_OR_NULL() usage

The corresponding function return ERR_PTR() values which
should be tested with IS_ERR(), not IS_ERR_OR_NULL() macro.
Especially it is not correct to do:

 if(IS_ERR_OR_NULL(value))
error = PTR_ERR(value);

Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
[jy0922.shim: apply to midgard r12p0_04rel0 except r5p0_06rel0 part]
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

gpu: arm: midgard: r12p0_04rel0: Add custom simple_ondemand devfreq governor data

Need custom upthreshold and downdifferential for mali devfreq.

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
[jy0922.shim: apply to midgard r12p0_04rel0]

gpu: arm: midgard: r12p0_04rel0: Restore frequency/voltage values on error paths in kbase_devfreq_target()

Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
[jy0922.shim: apply to midgard r12p0_04rel0]
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

gpu: arm: midgard: r12p0_04rel0: add regulator enable/disable calls

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
[jy0922.shim: apply to midgard r12p0_04rel0 with some modification]

gpu: arm: midgard: r12p0_04rel0: Workaround for missing last_status field

Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
[jy0922.shim: apply to midgard r12p0_04rel0]
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

gpu: arm: midgard: r12p0_04rel0: Fix 'struct devfreq_cooling_ops' related compilation break

There is no 'struct devfreq_cooling_ops' in current kernel tree
and 'struct devfreq_cooling_power' seems to be an equivalent of it.

Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
[jy0922.shim: apply to midgard r12p0_04rel0]
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

gpu: arm: midgard: r12p0_04rel0: Fix build warning about devfreq cooling device

This patch fixes the build warning according to new devfreq_cooling device
driver and make the frequency table as descending order.

Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
[jy0922.shim: apply to midgard r12p0_04rel0]
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

gpu: arm: midgard: r12p0_04rel0: change temperature var type to int in model_static_power()

Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
[jy0922.shim: apply to midgard r12p0_04rel0]
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

gpu: arm: midgard: r12p0_04rel0: add exynos5433 platform files

We should check more clock and regulator for DVFS.

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
[jy0922.shim: apply to midgard r12p0_04rel0 with removing some codes]

gpu: arm: midgard: remove choice in Kconfig of r12p0_04rel0

The choice of each mali version causes Kconfig errors like below,

$ make ARCH=arm64 menuconfig
scripts/kconfig/mconf  Kconfig
drivers/gpu/arm/midgard/r12p0_04rel0/Kconfig:126:warning: choice value used outside its choice group
drivers/gpu/arm/midgard/r12p0_04rel0/Kconfig:129:warning: choice value used outside its choice group
drivers/gpu/arm/midgard/r12p0_04rel0/Kconfig:132:warning: choice value used outside its choice group
drivers/gpu/arm/midgard/r12p0_04rel0/Kconfig:135:warning: choice value used outside its choice group
drivers/gpu/arm/midgard/r12p0_04rel0/Kconfig:137:warning: choice value used outside its choice group

Also remove configs for unused platform.

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

gpu: arm: midgard: support Kconfig for r12p0_04rel0

So, we can select mali midgard r12p0_04rel0 from Kconfig of midgard.

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

gpu: arm: midgard: add r12p0_04rel0 sources

This is mali midgard r12p0_04rel0 version from ARM.

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

gpu: arm: midgard: remove choice in Kconfig of r5p0_06rel0

The choice of each mali version causes Kconfig errors like below,

$ make ARCH=arm64 menuconfig
scripts/kconfig/mconf  Kconfig
drivers/gpu/arm/midgard/r12p0_02dev0/Kconfig:126:warning: choice value used outside its choice group
drivers/gpu/arm/midgard/r12p0_02dev0/Kconfig:129:warning: choice value used outside its choice group
drivers/gpu/arm/midgard/r12p0_02dev0/Kconfig:132:warning: choice value used outside its choice group
drivers/gpu/arm/midgard/r12p0_02dev0/Kconfig:135:warning: choice value used outside its choice group
drivers/gpu/arm/midgard/r12p0_02dev0/Kconfig:137:warning: choice value used outside its choice group

Also remove configs for unused platform.

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

gpu: arm: midgard: fix Kconfig for multiple driver

This will make Kconfig of midgard can select mali midgard version to
use.

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

arm64: tizen_tm2_defconfig: fix mali directory path for gator

The mali midgard path was changed to drivers/gpu/arm/midgard/r5p0_06rel0
from drivers/gpu/arm/midgard, so should fix mali path for gator in
defconfig.

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

gpu: arm: midgard: move to r5p0_06rel0

This is initial work to support multiple midgard driver in midgard
directory.

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

devfreq_cooling: return on allocation failure

If the allocation fails then we can't continue.

Fixes: a76caf55e5b3 ('thermal: Add devfreq cooling')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
[jy0922.shim: apply mainline patch]
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

thermal: devfreq_cooling: Make power a u64

The prototype of do_div() is:

uint32_t do_div(uint64_t *n, uint32_t base);

Make power u64 to avoid the following warning:

   drivers/thermal/devfreq_cooling.c: In function 'get_dynamic_power':
   drivers/thermal/devfreq_cooling.c:267:2: warning: comparison of distinct pointer types lacks a cast [enabled by default]
   drivers/thermal/devfreq_cooling.c:267:2: warning: right shift count >= width of type [enabled by default]
   drivers/thermal/devfreq_cooling.c:267:2: warning: passing argument 1 of '__div64_32' from incompatible pointer type [enabled by default]
   include/asm-generic/div64.h:35:17: note: expected 'uint64_t *' but argument is of type 'long unsigned int *'

Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Javi Merino <javi.merino@arm.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
[jy0922.shim: apply mainline patch]
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

thermal: devfreq_cooling: use a thermal_cooling_device for register and unregister

Be consistent with what other cooling devices do and return a struct
thermal_cooling_device * on register.  Also, for the unregister, accept
a struct thermal_cooling_device * as parameter.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Signed-off-by: Javi Merino <javi.merino@arm.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
[jy0922.shim: apply mainline patch]
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

devfreq_cooling: add trace information

Tracing is useful for debugging and performance tuning.  Add similar
traces to what's present in the cpu cooling device.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Ingo Molnar <mingo@redhat.com>
Signed-off-by: Javi Merino <javi.merino@arm.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
[jy0922.shim: apply from mainline with fixup of fuzz]
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

thermal: Add devfreq cooling

Add a generic thermal cooling device for devfreq, that is similar to
cpu_cooling.

The device must use devfreq.  In order to use the power extension of the
cooling device, it must have registered its OPPs using the OPP library.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Signed-off-by: Javi Merino <javi.merino@arm.com>
Signed-off-by: Ørjan Eide <orjan.eide@arm.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
[jy0922.shim: apply from mainline with fixup of fuzz]
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

thermal: remove devfreq cooling

Remove local old driver to apply original mainline driver for devfreq
cooling.

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

PM / devfreq: comments for get_dev_status usage updated

With the introduction of devfreq_update_stats(), governors
are not recommended to use get_dev_status() directly.

Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
[jy0922.shim: apply mainline patch]
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

PM / devfreq: cache the last call to get_dev_status()

The return value of get_dev_status() can be reused.  Cache it so that
other parts of the kernel can reuse it instead of having to call the
same function again.

Cc: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Javi Merino <javi.merino@arm.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
[jy0922.shim: apply mainline patch]
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

thermal: extend the cooling device API to include power information

Add three optional callbacks to the cooling device interface to allow
them to express power.  In addition to the callbacks, add helpers to
identify cooling devices that implement the power cooling device API.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Signed-off-by: Javi Merino <javi.merino@arm.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
[jy0922.shim: apply mainline patch]
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

Revert "PM: devfreq: Add the prototype of update_devfreq() to export"

This temporarily reverts commit d70aa318b6a80780e3134d8a07303fa72b95576b,
which will be re-applied after applying soem mainline commits.

Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>

gpu: mali: Drop TRACE_SYSTEM_STRING macro definition from mali_linux_trace.h

This fixes compilation warning:

In file included from include/trace/define_trace.h:90:0,
                 from drivers/gpu/arm/midgard/mali_linux_trace.h:211,
                 from drivers/gpu/arm/midgard/mali_kbase_core_linux.c:4199:
include/trace/ftrace.h:28:0: warning: "TRACE_SYSTEM_STRING" redefined
 #define TRACE_SYSTEM_STRING __app(TRACE_SYSTEM_VAR,__trace_system_name)
 ^
In file included from include/trace/define_trace.h:83:0,
                 from drivers/gpu/arm/midgard/mali_linux_trace.h:211,
                 from drivers/gpu/arm/midgard/mali_kbase_core_linux.c:4199:
drivers/gpu/arm/midgard/./mali_linux_trace.h:28:0: note: this is the location of the previous definition
 #define TRACE_SYSTEM_STRING __stringify(TRACE_SYSTEM)
 ^
In file included from include/trace/ftrace.h:134:0,
                 from include/trace/define_trace.h:90,
                 from drivers/gpu/arm/midgard/mali_linux_trace.h:211,
                 from drivers/gpu/arm/midgard/mali_kbase_core_linux.c:4199:
drivers/gpu/arm/midgard/./mali_linux_trace.h:28:0: warning: "TRACE_SYSTEM_STRING" redefined
 #define TRACE_SYSTEM_STRING __stringify(TRACE_SYSTEM)
 ^
In file included from include/trace/define_trace.h:90:0,
                 from drivers/gpu/arm/midgard/mali_linux_trace.h:211,
                 from drivers/gpu/arm/midgard/mali_kbase_core_linux.c:4199:
include/trace/ftrace.h:28:0: note: this is the location of the previous definition
 #define TRACE_SYSTEM_STRING __app(TRACE_SYSTEM_VAR,__trace_system_name)

Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>

arm64: tizen_tm2_defconfig: enable the sec-nfc legacy driver

This patch enables the sec-nfc legacy driver instead of s3fwrn5 for
neard interface. The legacy driver is used from nfc-manager which is
used as replacement of neard from Tizen.

Change-Id: I7a688738b69ca14723c8333cfca28c30ba2b9c84
Signed-off-by: Jihoon Jung <jh8801.jung@samsung.com>
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

nfc: change driver from neard interface to legacy sec-nfc

This enable the legacy nfc driver instead of neard interface.
It is required for nfc-manager and lsi nfc plugin implementation.

Change-Id: Ia77f105262e5c4899806e6310be6ae9cbc013ec9
Signed-off-by: Jihoon Jung <jh8801.jung@samsung.com>
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

arm: configs: merge odroid related defconfigs

There are two separated defconfig files for odroid including
tizen_odroidu3_defconfig and odroidxu3_defconfig. With just one
defconfig, it is possible to support both boards. So this patch
merges both odroid defconfigs into one tizen_odroid_defconfig
and also replaces defconfig from packaging spec file.

Change-Id: I5232ab6e5adfb98ea312e2fcfb9d149860c8764d
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

drm/exynos/dsi: mask frame-done interrupt

DSI driver is not really interested in this interrupt. It causes only
unnecessary code execution of interrupt handler and could possibly
cause FIFO overflow - as it triggers DSI interrupt handler to process
next DSI transfer. With this patch we will get rid of about 30 IRQ
handler calls per second.

Change-Id: I51b6a205cf235fab824888364980d358950b8c85
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>

drm/exynos/decon5433: mask HW trigger during frame send

Not masked TE during frame transmission results in shifted image in case of TV.
The patch fixes it.

Change-Id: I2d31a90371807b1f0ff2937f44ee0c51dbdf3638
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>

drm/exynos/decon5433: enable trigger for decon-tv

Decon-tv requires working trigger. Additionally whole trigger logic
was moved to one function.

Change-Id: I0d2aabc3ec3212024499868805ecfe15bdfa7023
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>

Revert "drm/exynos: decon: use deferred Trigger mode change"

Since HWTRIGGER can be enabled early this patch is not needed anymore.
Reverted patch complicates code and makes debugging more difficult -
DECON works in two different modes before and after suspend.
Since we have full control over all pipe components and we do full
configuration we can switch between HW/SW trigger without waiting
for platform suspend/resume.

This reverts commit 7a0e6fa3d120793a16b6bb16951ef2c436505080.

Change-Id: Ibe401305b9e80b70d9fcc8339cf2a9c40167879d
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>

drm/exynos/mic: workaround for disabling mic during modesetting

Exynos-DRM framework does not power cycle encoder during modesetting, but
DRM core does it for bridges, as a result MIC device is the only
power-cycled device in the chain DECON->MIC->DSI, it causes black screen.
It is a limitation/feature of DRM core.
The patch adds ugly workaround to skip power-cycling MIC during modesetting.
Alternative is to power-cycle all components during modesetting, it would
require adjustements in ExynosDRM framework and rework of some callbacks
in DSI driver.

Change-Id: I94fdb002f119a298b35f01a4abd41d65f7d7478b
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>

soc: exynos: fix support for domains without clocks defined

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Change-Id: Ia2c717a4fac9c073162a165793d897757e12a9ae

drm/exynos/decon5433: do not disable video on commit

There is no point in disabling video. In some cases it
results in blank screen.

Change-Id: Ifd242ea0ffbe0f30dbec8bb515bbc97dbfd332f6
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>

ARM64: dts: exynos5433: add MIC to power domain

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Change-Id: Idc7cf14c4802eb3c463debd3913c613f8926741a

drm/exynos: mic: add simple runtime pm support

Add simple runtime pm to let driver to control power domain. No runtime pm
callbacks are defined, because state of the driver is already handled by
the DRM core.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
[Add error routine for component_add like decon driver from probe]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I339fb38f1f5f44e8a58f0ac745e355d2a89aa037

drm/exynos: dsi: add simple runtime pm support

Add simple runtime pm to let driver to control power domain. No runtime pm
callbacks are defined, because state of the driver is already handled by
the DRM core.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
[Add error routine for component_add like decon driver from probe]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I77cdcf9b669c2bee45c14ba8d86f7fd1bbf8ba9c

drm/exynos: decon: add simple runtime pm support

Add simple runtime pm to let driver to control power domain. No runtime pm
callbacks are defined, because state of the driver is already handled by
the DRM core.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Change-Id: Ib2c6b6ef6e6577ef9a7259d1ae80202ab0e0a7c7

staging: logger: fix build error due to removed ki_nbytes

This patch fixes build error. Logger driver was removed
from mainline kernel and after that there was some changes and
one of them is that ki_nbytes member was removed from kiocb structure.
66ee59a fs: remove ki_nbytes

This patch makes count member of iov_iter structure to be used instead.

Change-Id: I070587d650596eb7ed93df7d99398f9e401a6579
Signed-off-by: Inki Dae <inki.dae@samsung.com>

drm/exynos/decon5433: Fix standalone update code

Documentation is not clear about the subject, but it seems that shadowed
registers should be updated only if STANDALONE_UPDATE_F bit is clear.
After completing update of shadowed registers driver should enable this bit.
Without this logic one can observe flickering, black screens or white noise.

Change-Id: Ia1e54423cd321bf7c8ac9e8cf90d1dc8c8d64daf
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>

mm/filemap: generic_file_read_iter(): check for zero reads unconditionally

If
 - generic_file_read_iter() gets called with a zero read length,
 - the read offset is at a page boundary,
 - IOCB_DIRECT is not set
-  and the page in question hasn't made it into the page cache yet,
then do_generic_file_read() will trigger a readahead with a req_size hint
of zero.

Since roundup_pow_of_two(0) is undefined, UBSAN reports

  UBSAN: Undefined behaviour in include/linux/log2.h:63:13
  shift exponent 64 is too large for 64-bit type 'long unsigned int'
  CPU: 3 PID: 1017 Comm: sa1 Tainted: G L 4.5.0-next-20160318+ #14
  [...]
  Call Trace:
   [...]
   [<ffffffff813ef61a>] ondemand_readahead+0x3aa/0x3d0
   [<ffffffff813ef61a>] ? ondemand_readahead+0x3aa/0x3d0
   [<ffffffff813c73bd>] ? find_get_entry+0x2d/0x210
   [<ffffffff813ef9c3>] page_cache_sync_readahead+0x63/0xa0
   [<ffffffff813cc04d>] do_generic_file_read+0x80d/0xf90
   [<ffffffff813cc955>] generic_file_read_iter+0x185/0x420
   [...]
   [<ffffffff81510b06>] __vfs_read+0x256/0x3d0
   [...]

when get_init_ra_size() gets called from ondemand_readahead().

The net effect is that the initial readahead size is arch dependent for
requested read lengths of zero: for example, since

  1UL << (sizeof(unsigned long) * 8)

evaluates to 1 on x86 while its result is 0 on ARMv7, the initial readahead
size becomes 4 on the former and 0 on the latter.

What's more, whether or not the file access timestamp is updated for zero
length reads is decided differently for the two cases of IOCB_DIRECT
being set or cleared: in the first case, generic_file_read_iter()
explicitly skips updating that timestamp while in the latter case, it is
always updated through the call to do_generic_file_read().

According to POSIX, zero length reads "do not modify the last data access
timestamp" and thus, the IOCB_DIRECT behaviour is POSIXly correct.

Let generic_file_read_iter() unconditionally check the requested read
length at its entry and return immediately with success if it is zero.

Signed-off-by: Nicolai Stange <nicstange@gmail.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[Backport from mainline to remove UBSAN warning during login]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I4f23b085363201c79d63601a69f287f26e55fafb

signal: move the "sig < SIGRTMIN" check into siginmask(sig)

All the users of siginmask() must ensure that sig < SIGRTMIN.  sig_fatal()
doesn't and this is wrong:

UBSAN: Undefined behaviour in kernel/signal.c:911:6
shift exponent 32 is too large for 32-bit type 'long unsigned int'

the patch doesn't add the neccesary check to sig_fatal(), it moves the
check into siginmask() and updates other callers.

Link: http://lkml.kernel.org/r/20160517195052.GA15187@redhat.com
Reported-by: Meelis Roos <mroos@linux.ee>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[Backport from mainline to remove UBSAN warning in sending signal]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Icb12de70772b563ba112f5f6e490731e4db119d1

USB: EHCI: avoid undefined pointer arithmetic and placate UBSAN

Several people have reported that UBSAN doesn't like the pointer
arithmetic in ehci_hub_control():

u32 __iomem *status_reg = &ehci->regs->port_status[
(wIndex & 0xff) - 1];
u32 __iomem *hostpc_reg = &ehci->regs->hostpc[(wIndex & 0xff) - 1];

If wIndex is 0 (and it often is), these calculations underflow and
UBSAN complains.

According to the C standard, pointer computations leading to locations
outside the bounds of an array object (other than 1 position past the
end) are undefined.  In this case, the compiler would be justified in
concluding the wIndex can never be 0 and then optimizing away the
tests for !wIndex that occur later in the subroutine.  (Although,
since ehci->regs->port_status and ehci->regs->hostpc are both 0-length
arrays and are thus GCC extensions to the C standard, it's not clear
what the compiler is really allowed to do.)

At any rate, we can avoid all these difficulties, at the cost of
making the code slightly longer, by not decrementing the index when it
is equal to 0.  The runtime effect is minimal, and anyway
ehci_hub_control() is not on a hot path.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
Reported-by: Meelis Roos <mroos@linux.ee>
Reported-by: Martin_MOKREJÅ <mmokrejs@gmail.com>
Reported-by: "Navin P.S" <navinp1912@gmail.com>
CC: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[Backport from mainline to remove UBSAN warning on usb-ehci]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Iead9feb0ae5b53d48baa7603f1808fc898b31127

arm: ubsan: select ARCH_HAS_UBSAN_SANITIZE_ALL

To enable UBSAN on arm, this patch enables ARCH_HAS_UBSAN_SANITIZE_ALL
from arm confiuration. Basic kernel booting is tested on arm kernel
enabled CONFIG_UBSAN_SANITIZE_ALL from Exynos5422 based Odroid-XU3
board.

Change-Id: I9480a9af713b88eff2a90df11f78e1feb97eac30
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

ARM: 8471/1: need to save/restore arm register(r11) when it is corrupted

In cpu_v7_do_suspend routine, r11 is used while it is NOT
saved/restored, different compiler may have different usage
of ARM general registers, so it may cause issues during
calling cpu_v7_do_suspend.

We meet kernel fault occurs when using GCC 4.8.3, r11 contains
valid value before calling into cpu_v7_do_suspend, but when returned
from this routine, r11 is corrupted and lead to kernel fault.
Doing save/restore for those corrupted registers is a must in
assemble code.

Signed-off-by: Anson Huang <Anson.Huang@freescale.com>
Reviewed-by: Nicolas Pitre <nico@linaro.org>
Cc: <stable@vger.kernel.org> # v3.3+
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[Backport from mainline to fix boot hangup on arm with UBSAN]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I2c0bb7b8e9d4a0489a4e9e08c65ed7b39fea9ee8

pinctrl: samsung: fix wakeup irq for extended eint

For extended eint bank, it should use maks1 for bit from 32 to 63
as its ext offset. So this patch fixes wakeup irq setting for
extended eit of exynos5433 with adding eint mask1 setting.

Without considering extended eint, setting wakeup on ext eint pin
causes wrong offset for eint mask, so UBSAN warning is repored
like following:

   UBSAN: Undefined behaviour in drivers/pinctrl/samsung/pinctrl-exynos.c:376:26
   shift exponent 8217 is too large for 64-bit type 'long unsigned int'
   Call trace:
   [<ffffffc00008f440>] dump_backtrace+0x0/0x218
   [<ffffffc00008f668>] show_stack+0x10/0x20
   [<ffffffc00159f3b8>] dump_stack+0x80/0xfc
   [<ffffffc00159f558>] ubsan_epilogue+0x10/0x6c
   [<ffffffc00159fe38>] __ubsan_handle_shift_out_of_bounds+0x188/0x1bc
   [<ffffffc000785514>] exynos_wkup_irq_set_wake+0x104/0x138
   [<ffffffc0001647b0>] set_irq_wake_real+0x70/0xc0
   [<ffffffc000164a70>] irq_set_irq_wake+0x158/0x1b0
   [...]

Change-Id: I6d55182609c982de702936ddb0045639df0e5ef0
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

arm64: tm2_defconfig: do not compile unnecessary drivers

Patch c89511d3180fe37cdee67f9bcd2876fefa26a057 was including in
not specifying the compilation status of some drivers in the RC
system.

In order to not compile them specify their entries with the "is
not set" flag in the config file.

Change-Id: I09ff34c020bc7fd039bfaf7d5ba177205f7256fa
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Suggested-by: Seung-Woo Kim <sw0312.kim@samsung.com>

arm64: dts: exynos5433: tm2/tm2e: add ir-spi device node

The tm2 and tm2e boards both have an irled connected to the
SPI MOSI line for remote controlling. Therefore, enable it in
their related device tree node.

Add the fixed regulator which powers the LED, as well.

Change-Id: Ie47bebae3efaebbd2d18b3e5f5d6fbec68486b1d
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>

arm64: tm2_defconfig: add support for the ir-spi driver

Enable the CONFIG_IR_SPI flag for the TM2 default
configuration.

Change-Id: Ic2f08b7b5480d7de4bb8442323e100742642405a
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>

[media] rc: ir-spi: add support for IR LEDs connected with SPI

The ir-spi is a simple device driver which supports the
connection between an IR LED and the MOSI line of an SPI device.

The driver, indeed, uses the SPI framework to stream the raw data
provided by userspace through a character device. The chardev is
handled by the LIRC framework and its functionality basically
provides:

 - raw write: data to be sent to the SPI and then streamed to the
   MOSI line;
 - set frequency: sets the frequency whith which the data should
   be sent;
 - set length: sets the data length. This information is
   optional, if the length is set, then userspace should send raw
   data only with that length; while if the length is set to '0',
   then the driver will figure out himself the length of the data
   based on the length of the data written on the character
   device.
   The latter is not recommended, though, as the driver, at
   any write, allocates and deallocates a buffer where the data
   from userspace are stored.

The driver provides three feedback commands:

 - get length: reads the length set and (as mentioned), if the
   length is '0' it will be calculated at any write
 - get frequency: the driver reports the frequency. If userpace
   doesn't set the frequency, the driver will use a default value
   of 38000Hz.

The character device is created under /dev/lircX name, where X is
and ID assigned by the LIRC framework.

Example of usage:

        int fd, ret;
        ssize_t n;
        uint32_t val = 0;

        fd = open("/dev/lirc0", O_RDWR);
        if (fd < 0) {
                fprintf(stderr, "unable to open the device\n");
                return -1;
        }

        /* ioctl set frequency and length parameters */
        val = 6430;
        ret = ioctl(fd, LIRC_SET_LENGTH, &val);
        if (ret < 0)
                fprintf(stderr, "LIRC_SET_LENGTH failed\n");
        val = 608000;
        ret = ioctl(fd, LIRC_SET_FREQUENCY, &val);
        if (ret < 0)
                fprintf(stderr, "LIRC_SET_FREQUENCY failed\n");

        /* read back length and frequency parameters */
        ret = ioctl(fd, LIRC_GET_LENGTH, &val);
        if (ret < 0)
                fprintf(stderr, "LIRC_GET_LENGTH failed\n");
        else
                fprintf(stdout, "legnth = %u\n", val);

        ret = ioctl(fd, LIRC_GET_FREQUENCY, &val);
        if (ret < 0)
                fprintf(stderr, "LIRC_GET_FREQUENCY failed\n");
        else
                fprintf(stdout, "frequency = %u\n", val);

        /* write data to device */
        n = write(fd, b, 6430);
        if (n < 0) {
                fprintf(stderr, "unable to write to the device\n");
                ret = -1;
        } else if (n != 6430) {
                fprintf(stderr, "failed to write everything, wrote %ld instead\n", n);
                ret = -1;
        } else {
                fprintf(stdout, "written all the %ld data\n", n);
        }

        close(fd);

The driver supports multi task access, but all the processes
which hold the driver should use the same length and frequency
parameters.

Change-Id: I323d7dd4a56d6dcf48f2c695293822eb04bdb85f
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>

[media] include: lirc: add set length and frequency ioctl options

The Lirc framework works mainly with receivers, but there is
nothing that prevents us from using it for transmitters as well.

For that we need to have more control on the device frequency to
set (which is a new concept fro LIRC) and we also need to provide
to userspace, as feedback, the values of the used frequency and
length.

Add the LIRC_SET_LENGTH, LIRC_GET_FREQUENCY and
LIRC_SET_FREQUENCY ioctl commands in order to allow the above
mentioned operations.

Change-Id: I50b08e4da89a61f4b14f8a2752b905bc9e4a1d34
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>

spi: s3c64xx: use unsigned type for fifo handling variables

The 'quirks' variable cannot ever be negative, therefore use u8
instead of int. The 8 bit size is given from the fact that
currently the quirks variable has very few statuses.

The rx_lvl_offset and tx_st_done store shift values, so that u8
is a proper size.

fifo_lvl_mask stores a series of masks, to be in we will keep the
32 bit size.

Change-Id: I949160c9dfd68d6dce5c2385c911269f5b6d1505
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>

spi: s3c64xx: add the BROKEN_CS case when setting up the transfer

The CS line might be disconneced ("broken"), therefore unused.
In this case, the device doesn't need to wait for the user to
handle the CS line for selecting the slave. The data will then be
automatically transferred without taking the CS line status into
account.

Change-Id: Ibddf87721b7d882efbdad9c978b79a3e19189b3e
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>

clk: exynos5433: use CLK_IGNORE_UNUSED for the SPI3 related clock

The SPI 3 bus uses two clocks, a bus clock and an input clock.
Do not disable the clocks when unused in order to allow access to
the SPI 3 device.

Change-Id: I5fbc360e4b0ed2043b0bf1f2dd251f3e913082f3
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>

ARM: dts: Remove fimd node from exynos5422-odroidxu3-common

FIMD device is not used at all on Exynos5422-based Odroid XU3-lite and
XU4. XU3 board theorethically can support FIMD with DisplayPort
connector, but due to hw limitation/design it doesn't work in most
cases. It is also not even enabled in XU3 dts file.

FIMD node was enabled mainly due to limitation of early Exynos DRM
driver, which didn't initialize properly when no FIMD device was
available. This node can be now safely removed from XU3-common dtsi and
added layer to Odroid XU3 dts, when Display Port driver gets enabled.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
[mainline backport of commit 616d289abac9c63f5a5a56c0deb088360f4aed06]
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Change-Id: I616d289abac9c63f5a5a56c0deb088360f4aed06

ARM: dts: Add async-bridge clock to MFC power domain for Exynos5420

The MFC IP is also inter-connected by an Async-Bridge so the CLK_ACLK333
has to be ungated during a power domain switch. Trying to do it when the
clock is gated will fail and lead to an imprecise external abort error
when the driver tries to access the MFC registers with the PD disabled.

For example, if the s5p-mfc module is removed and the MFC PD turned off:

[  186.835606] Power domain power-domain@10044060 disable failed
[  186.835671] s5p-mfc 11000000.codec: Removing 11000000.codec
[  186.837670] Power domain power-domain@10044060 disable failed

And when the module is inserted again:

[ 2395.176956] s5p_mfc_wait_for_done_dev:34: Interrupt (dev->int_type:0, command:12) timed out
[ 2395.177031] s5p_mfc_init_hw:272: Failed to load firmware
[ 2395.177384] Unhandled fault: imprecise external abort (0x1406) at 0x00000000
[ 2395.177441] pgd = ec3b4000
[ 2395.177467] [00000000] *pgd=00000000
[ 2395.177507] Internal error: : 1406 [#1] PREEMPT SMP ARM
[ 2395.177550] Modules linked in: s5p_mfc mwifiex_sdio mwifiex uvcvideo s5p_jpeg v4l2_mem2mem videobuf2_vmalloc videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_core v4l2_common videodev media [last unloaded: s5p_mfc]
[ 2395.177774] CPU: 1 PID: 2382 Comm: v4l_id Tainted: G        W       4.6.0-rc6-next-20160502-00010-g7730dc64d2c1-dirty #179
[ 2395.177857] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 2395.177906] task: ed275500 ti: e6c8c000 task.ti: e6c8c000
[ 2395.177996] PC is at s5p_mfc_reset+0x1c4/0x284 [s5p_mfc]
[ 2395.178057] LR is at s5p_mfc_reset+0x1a4/0x284 [s5p_mfc]

This patch fixes this issue by adding the CLK_ACLK333 as an Async-Bridge
clock for the MFC power domain, so the PD configuration works properly.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
[backport of mainline commit 94aed538e032d82287023beb9c59ee80f03a1493]
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Change-Id: I94aed538e032d82287023beb9c59ee80f03a1493

clk: exynos5420: Set ID for aclk333 gate clock

The aclk333 clock needs to be ungated during the MFC power domain switch,
so set the clock ID to allow the Exynos power domain logic to lookup this
clock if is defined in the MFC PD device tree node.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
[backport of mainline commit 34cba900375ec1751a87d3655ad03b9a5b022362]
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Change-Id: I34cba900375ec1751a87d3655ad03b9a5b022362

s5p-mfc: don't close instance after free OUTPUT buffers

User-space applications can use the VIDIOC_REQBUFS ioctl to determine if a
memory mapped, user pointer or DMABUF based I/O is supported by the driver.

So a set of VIDIOC_REQBUFS ioctl calls will be made with count 0 and then
the real VIDIOC_REQBUFS call with count == n. But for count 0, the driver
not only frees the buffer but also closes the MFC instance and s5p_mfc_ctx
state is set to MFCINST_FREE.

The VIDIOC_REQBUFS handler for the output device checks if the s5p_mfc_ctx
state is set to MFCINST_INIT (which happens on an VIDIOC_S_FMT) and fails
otherwise. So after a VIDIOC_REQBUFS(n), future VIDIOC_REQBUFS(n) calls
will fails unless a VIDIOC_S_FMT ioctl calls happens before the reqbufs.

But applications may first set the format and then attempt to determine
the I/O methods supported by the driver (for example Gstramer does it) so
the state won't be set to MFCINST_INIT again and VIDIOC_REQBUFS will fail.

To avoid this issue, only free the buffers on VIDIOC_REQBUFS(0) but don't
close the MFC instance to allow future VIDIOC_REQBUFS(n) calls to succeed.

[javier: Rewrote changelog to explain the problem more detailed]

Signed-off-by: ayaka <ayaka@soulik.info>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Acked-by: Nicolas Dufresne <nicolas@collabora.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
[backport of mainline commit 9bd5d8696fd50a10d830e2ad7f9d4e67e0bbbae2]
Signed-of-by: Marek Szyprowski <m.szyprowski@samsung.com>
Change-Id: I9bd5d8696fd50a10d830e2ad7f9d4e67e0bbbae2

s5p-mfc: Fix race between s5p_mfc_probe() and s5p_mfc_open()

The s5p_mfc_probe() function registers the video devices before all the
resources needed by s5p_mfc_open() are correctly initalized.

So if s5p_mfc_open() function is called before s5p_mfc_probe() finishes
(since the video dev is already registered), a NULL pointer dereference
will happen due s5p_mfc_open() accessing uninitialized vars such as the
struct s5p_mfc_dev .watchdog_timer and .mfc_ops fields.

An example is following BUG caused by add_timer() getting a NULL pointer:

[   45.765374] kernel BUG at kernel/time/timer.c:790!
[   45.765381] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
...
[   45.766149] [<c016fdf4>] (mod_timer) from [<bf181d18>] (s5p_mfc_open+0x274/0x4d4 [s5p_mfc])
[   45.766416] [<bf181d18>] (s5p_mfc_open [s5p_mfc]) from [<bf0214a0>] (v4l2_open+0x9c/0x100 [videodev])
[   45.766547] [<bf0214a0>] (v4l2_open [videodev]) from [<c01e355c>] (chrdev_open+0x9c/0x178)
[   45.766575] [<c01e355c>] (chrdev_open) from [<c01dceb4>] (do_dentry_open+0x1e0/0x300)
[   45.766595] [<c01dceb4>] (do_dentry_open) from [<c01ec2f0>] (path_openat+0x800/0x10d4)
[   45.766610] [<c01ec2f0>] (path_openat) from [<c01ed8b8>] (do_filp_open+0x5c/0xc0)
[   45.766624] [<c01ed8b8>] (do_filp_open) from [<c01de218>] (do_sys_open+0x10c/0x1bc)
[   45.766642] [<c01de218>] (do_sys_open) from [<c01078c0>] (ret_fast_syscall+0x0/0x3c)
[   45.766655] Code: eaffffe3 e3a00001 e28dd008 e8bd81f0 (e7f001f2)

Fix it by registering the video devs as the last step in s5p_mfc_probe().

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
[backport of mainline commit 6311f1261f59ce5e51fbe5cc3b5e7737197316ac]
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Change-Id: I43355e4eeaa913d3b63a41a5621a122f4771982f

mmc: dw_mmc: remove UBSAN warning in dw_mci_setup_bus()

This patch removes following UBSAN warnings in dw_mci_setup_bus().

  UBSAN: Undefined behaviour in drivers/mmc/host/dw_mmc.c:1102:14
  shift exponent 250 is too large for 32-bit type 'unsigned int'
  Call trace:
  [<ffffff90080908a8>] dump_backtrace+0x0/0x380
  [<ffffff9008090c3c>] show_stack+0x14/0x20
  [<ffffff90087457b8>] dump_stack+0xe0/0x120
  [<ffffff90087b1360>] ubsan_epilogue+0x18/0x68
  [<ffffff90087b1a94>] __ubsan_handle_shift_out_of_bounds+0x18c/0x1bc
  [<ffffff9008d89cb8>] dw_mci_setup_bus+0x3a0/0x438
  [...]

  UBSAN: Undefined behaviour in drivers/mmc/host/dw_mmc.c:1132:27
  shift exponent 250 is too large for 32-bit type 'unsigned int'
  Call trace:
  [<ffffff90080908a8>] dump_backtrace+0x0/0x380
  [<ffffff9008090c3c>] show_stack+0x14/0x20
  [<ffffff90087457b8>] dump_stack+0xe0/0x120
  [<ffffff90087b1360>] ubsan_epilogue+0x18/0x68
  [<ffffff90087b1a94>] __ubsan_handle_shift_out_of_bounds+0x18c/0x1bc
  [<ffffff9008d89c9c>] dw_mci_setup_bus+0x384/0x438
  [...]

The warnings are caused because of bit shift which is used to
filter spamming message for CONFIG_MMC_CLKGATE, but the config is
already removed. So this patch just removes the shift.

[Backport for current version.]

Change-Id: I1760db1b0e42ddd490aa7539e6c1474a047387c4
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

ARM: add support for generic early_ioremap/early_memremap

This enables the generic early_ioremap implementation for ARM.

It uses the fixmap region reserved for kmap. Since early_ioremap
is only supported before paging_init(), and kmap is only supported
afterwards, this is guaranteed not to cause any clashes.

Tested-by: Ryan Harkin <ryan.harkin@linaro.org>
Reviewed-by: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
[backport from mainline to support ioremap on earlycon for arm target]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I4e2d88b47a4c1f31882632b702df6a627b109308

ARM: 8415/1: early fixmap support for earlycon

Add early fixmap support, initially to support permanent, fixed
mapping support for early console. A temporary, early pte is
created which is migrated to a permanent mapping in paging_init.
This is also needed since the attributes may change as the memory
types are initialized. The 3MiB range of fixmap spans two pte
tables, but currently only one pte is created for early fixmap
support.

Re-add FIX_KMAP_BEGIN to the index calculation in highmem.c since
the index for kmap does not start at zero anymore. This reverts
4221e2e6b316 ("ARM: 8031/1: fixmap: remove FIX_KMAP_BEGIN and
FIX_KMAP_END") to some extent.

Cc: Mark Salter <msalter@redhat.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Laura Abbott <lauraa@codeaurora.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[backport from mainline to support ioremap on earlycon for arm target]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Ifeee5e94d70d87b74b8e0d2bb3b4d32f6d946a01

usb: xhci: fix xhci locking up during hcd remove

[ Upstream commit ad6b1d914a9e07f3b9a9ae3396f3c840d0070539 ]

The problem seems to be that if a new device is detected
while we have already removed the shared HCD, then many of the
xhci operations (e.g.  xhci_alloc_dev(), xhci_setup_device())
hang as command never completes.

I don't think XHCI can operate without the shared HCD as we've
already called xhci_halt() in xhci_only_stop_hcd() when shared HCD
goes away. We need to prevent new commands from being queued
not only when HCD is dying but also when HCD is halted.

The following lockup was detected while testing the otg state
machine.

[  178.199951] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
[  178.205799] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 1
[  178.214458] xhci-hcd xhci-hcd.0.auto: hcc params 0x0220f04c hci version 0x100 quirks 0x00010010
[  178.223619] xhci-hcd xhci-hcd.0.auto: irq 400, io mem 0x48890000
[  178.230677] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[  178.237796] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[  178.245358] usb usb1: Product: xHCI Host Controller
[  178.250483] usb usb1: Manufacturer: Linux 4.0.0-rc1-00024-g6111320 xhci-hcd
[  178.257783] usb usb1: SerialNumber: xhci-hcd.0.auto
[  178.267014] hub 1-0:1.0: USB hub found
[  178.272108] hub 1-0:1.0: 1 port detected
[  178.278371] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
[  178.284171] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 2
[  178.294038] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
[  178.301183] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[  178.308776] usb usb2: Product: xHCI Host Controller
[  178.313902] usb usb2: Manufacturer: Linux 4.0.0-rc1-00024-g6111320 xhci-hcd
[  178.321222] usb usb2: SerialNumber: xhci-hcd.0.auto
[  178.329061] hub 2-0:1.0: USB hub found
[  178.333126] hub 2-0:1.0: 1 port detected
[  178.567585] dwc3 48890000.usb: usb_otg_start_host 0
[  178.572707] xhci-hcd xhci-hcd.0.auto: remove, state 4
[  178.578064] usb usb2: USB disconnect, device number 1
[  178.586565] xhci-hcd xhci-hcd.0.auto: USB bus 2 deregistered
[  178.592585] xhci-hcd xhci-hcd.0.auto: remove, state 1
[  178.597924] usb usb1: USB disconnect, device number 1
[  178.603248] usb 1-1: new high-speed USB device number 2 using xhci-hcd
[  190.597337] INFO: task kworker/u4:0:6 blocked for more than 10 seconds.
[  190.604273]       Not tainted 4.0.0-rc1-00024-g6111320 #1058
[  190.610228] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  190.618443] kworker/u4:0    D c05c0ac0     0     6      2 0x00000000
[  190.625120] Workqueue: usb_otg usb_otg_work
[  190.629533] [<c05c0ac0>] (__schedule) from [<c05c10ac>] (schedule+0x34/0x98)
[  190.636915] [<c05c10ac>] (schedule) from [<c05c1318>] (schedule_preempt_disabled+0xc/0x10)
[  190.645591] [<c05c1318>] (schedule_preempt_disabled) from [<c05c23d0>] (mutex_lock_nested+0x1ac/0x3fc)
[  190.655353] [<c05c23d0>] (mutex_lock_nested) from [<c046cf8c>] (usb_disconnect+0x3c/0x208)
[  190.664043] [<c046cf8c>] (usb_disconnect) from [<c0470cf0>] (_usb_remove_hcd+0x98/0x1d8)
[  190.672535] [<c0470cf0>] (_usb_remove_hcd) from [<c0485da8>] (usb_otg_start_host+0x50/0xf4)
[  190.681299] [<c0485da8>] (usb_otg_start_host) from [<c04849a4>] (otg_set_protocol+0x5c/0xd0)
[  190.690153] [<c04849a4>] (otg_set_protocol) from [<c0484b88>] (otg_set_state+0x170/0xbfc)
[  190.698735] [<c0484b88>] (otg_set_state) from [<c0485740>] (otg_statemachine+0x12c/0x470)
[  190.707326] [<c0485740>] (otg_statemachine) from [<c0053c84>] (process_one_work+0x1b4/0x4a0)
[  190.716162] [<c0053c84>] (process_one_work) from [<c00540f8>] (worker_thread+0x154/0x44c)
[  190.724742] [<c00540f8>] (worker_thread) from [<c0058f88>] (kthread+0xd4/0xf0)
[  190.732328] [<c0058f88>] (kthread) from [<c000e810>] (ret_from_fork+0x14/0x24)
[  190.739898] 5 locks held by kworker/u4:0/6:
[  190.744274]  #0:  ("%s""usb_otg"){.+.+.+}, at: [<c0053bf4>] process_one_work+0x124/0x4a0
[  190.752799]  #1:  ((&otgd->work)){+.+.+.}, at: [<c0053bf4>] process_one_work+0x124/0x4a0
[  190.761326]  #2:  (&otgd->fsm.lock){+.+.+.}, at: [<c048562c>] otg_statemachine+0x18/0x470
[  190.769934]  #3:  (usb_bus_list_lock){+.+.+.}, at: [<c0470ce8>] _usb_remove_hcd+0x90/0x1d8
[  190.778635]  #4:  (&dev->mutex){......}, at: [<c046cf8c>] usb_disconnect+0x3c/0x208
[  190.786700] INFO: task kworker/1:0:14 blocked for more than 10 seconds.
[  190.793633]       Not tainted 4.0.0-rc1-00024-g6111320 #1058
[  190.799567] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  190.807783] kworker/1:0     D c05c0ac0     0    14      2 0x00000000
[  190.814457] Workqueue: usb_hub_wq hub_event
[  190.818866] [<c05c0ac0>] (__schedule) from [<c05c10ac>] (schedule+0x34/0x98)
[  190.826252] [<c05c10ac>] (schedule) from [<c05c4e40>] (schedule_timeout+0x13c/0x1ec)
[  190.834377] [<c05c4e40>] (schedule_timeout) from [<c05c19f0>] (wait_for_common+0xbc/0x150)
[  190.843062] [<c05c19f0>] (wait_for_common) from [<bf068a3c>] (xhci_setup_device+0x164/0x5cc [xhci_hcd])
[  190.852986] [<bf068a3c>] (xhci_setup_device [xhci_hcd]) from [<c046b7f4>] (hub_port_init+0x3f4/0xb10)
[  190.862667] [<c046b7f4>] (hub_port_init) from [<c046eb64>] (hub_event+0x704/0x1018)
[  190.870704] [<c046eb64>] (hub_event) from [<c0053c84>] (process_one_work+0x1b4/0x4a0)
[  190.878919] [<c0053c84>] (process_one_work) from [<c00540f8>] (worker_thread+0x154/0x44c)
[  190.887503] [<c00540f8>] (worker_thread) from [<c0058f88>] (kthread+0xd4/0xf0)
[  190.895076] [<c0058f88>] (kthread) from [<c000e810>] (ret_from_fork+0x14/0x24)
[  190.902650] 5 locks held by kworker/1:0/14:
[  190.907023]  #0:  ("usb_hub_wq"){.+.+.+}, at: [<c0053bf4>] process_one_work+0x124/0x4a0
[  190.915454]  #1:  ((&hub->events)){+.+.+.}, at: [<c0053bf4>] process_one_work+0x124/0x4a0
[  190.924070]  #2:  (&dev->mutex){......}, at: [<c046e490>] hub_event+0x30/0x1018
[  190.931768]  #3:  (&port_dev->status_lock){+.+.+.}, at: [<c046eb50>] hub_event+0x6f0/0x1018
[  190.940558]  #4:  (&bus->usb_address0_mutex){+.+.+.}, at: [<c046b458>] hub_port_init+0x58/0xb10

Change-Id: I4bde4137a49c92c98f5ec36e300a1fb54d50090d
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
[Retrived from linux-stable:4.1.y to fix usb-otg deadlock]
Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com>

bitops.h: correctly handle rol32 with 0 byte shift

ROL on a 32 bit integer with a shift of 32 or more is undefined and the
result is arch-dependent. Avoid this by handling the trivial case of
roling by 0 correctly.

The trivial solution of checking if shift is 0 breaks gcc's detection
of this code as a ROL instruction, which is unacceptable.

This bug was reported and fixed in GCC
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57157):

The standard rotate idiom,

  (x << n) | (x >> (32 - n))

is recognized by gcc (for concreteness, I discuss only the case that x
is an uint32_t here).

However, this is portable C only for n in the range 0 < n < 32. For n
== 0, we get x >> 32 which gives undefined behaviour according to the
C standard (6.5.7, Bitwise shift operators). To portably support n ==
0, one has to write the rotate as something like

  (x << n) | (x >> ((-n) & 31))

And this is apparently not recognized by gcc.

Note that this is broken on older GCCs and will result in slower ROL.

Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[Backport from mainline to fix ubsan report]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I47fcb9807778615fff4972fa92dc7b3143e0ef3d

ext4: silence UBSAN in ext4_mb_init()

Currently, in ext4_mb_init(), there's a loop like the following:

  do {
    ...
    offset += 1 << (sb->s_blocksize_bits - i);
    i++;
  } while (i <= sb->s_blocksize_bits + 1);

Note that the updated offset is used in the loop's next iteration only.

However, at the last iteration, that is at i == sb->s_blocksize_bits + 1,
the shift count becomes equal to (unsigned)-1 > 31 (c.f. C99 6.5.7(3))
and UBSAN reports

  UBSAN: Undefined behaviour in fs/ext4/mballoc.c:2621:15
  shift exponent 4294967295 is too large for 32-bit type 'int'
  [...]
  Call Trace:
   [<ffffffff818c4d25>] dump_stack+0xbc/0x117
   [<ffffffff818c4c69>] ? _atomic_dec_and_lock+0x169/0x169
   [<ffffffff819411ab>] ubsan_epilogue+0xd/0x4e
   [<ffffffff81941cac>] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254
   [<ffffffff81941ab1>] ? __ubsan_handle_load_invalid_value+0x158/0x158
   [<ffffffff814b6dc1>] ? kmem_cache_alloc+0x101/0x390
   [<ffffffff816fc13b>] ? ext4_mb_init+0x13b/0xfd0
   [<ffffffff814293c7>] ? create_cache+0x57/0x1f0
   [<ffffffff8142948a>] ? create_cache+0x11a/0x1f0
   [<ffffffff821c2168>] ? mutex_lock+0x38/0x60
   [<ffffffff821c23ab>] ? mutex_unlock+0x1b/0x50
   [<ffffffff814c26ab>] ? put_online_mems+0x5b/0xc0
   [<ffffffff81429677>] ? kmem_cache_create+0x117/0x2c0
   [<ffffffff816fcc49>] ext4_mb_init+0xc49/0xfd0
   [...]

Observe that the mentioned shift exponent, 4294967295, equals (unsigned)-1.

Unless compilers start to do some fancy transformations (which at least
GCC 6.0.0 doesn't currently do), the issue is of cosmetic nature only: the
such calculated value of offset is never used again.

Silence UBSAN by introducing another variable, offset_incr, holding the
next increment to apply to offset and adjust that one by right shifting it
by one position per loop iteration.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114701
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112161

Cc: stable@vger.kernel.org
Signed-off-by: Nicolai Stange <nicstange@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
[Backport from mainline to resolve ubsan report]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Ib81c9554712b6e5b47cf303b99a290939741a1e4

ext4: address UBSAN warning in mb_find_order_for_block()

Currently, in mb_find_order_for_block(), there's a loop like the following:

  while (order <= e4b->bd_blkbits + 1) {
    ...
    bb += 1 << (e4b->bd_blkbits - order);
  }

Note that the updated bb is used in the loop's next iteration only.

However, at the last iteration, that is at order == e4b->bd_blkbits + 1,
the shift count becomes negative (c.f. C99 6.5.7(3)) and UBSAN reports

  UBSAN: Undefined behaviour in fs/ext4/mballoc.c:1281:11
  shift exponent -1 is negative
  [...]
  Call Trace:
   [<ffffffff818c4d35>] dump_stack+0xbc/0x117
   [<ffffffff818c4c79>] ? _atomic_dec_and_lock+0x169/0x169
   [<ffffffff819411bb>] ubsan_epilogue+0xd/0x4e
   [<ffffffff81941cbc>] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254
   [<ffffffff81941ac1>] ? __ubsan_handle_load_invalid_value+0x158/0x158
   [<ffffffff816e93a0>] ? ext4_mb_generate_from_pa+0x590/0x590
   [<ffffffff816502c8>] ? ext4_read_block_bitmap_nowait+0x598/0xe80
   [<ffffffff816e7b7e>] mb_find_order_for_block+0x1ce/0x240
   [...]

Unless compilers start to do some fancy transformations (which at least
GCC 6.0.0 doesn't currently do), the issue is of cosmetic nature only: the
such calculated value of bb is never used again.

Silence UBSAN by introducing another variable, bb_incr, holding the next
increment to apply to bb and adjust that one by right shifting it by one
position per loop iteration.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114701
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112161

Cc: stable@vger.kernel.org
Signed-off-by: Nicolai Stange <nicstange@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
[Backport from mainline to resolve ubsan report]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I25c4298e7e5c971a7f7c29710b3679953dee4ff0

ubsan: fix tree-wide -Wmaybe-uninitialized false positives

-fsanitize=* options makes GCC less smart than usual and increase number
of 'maybe-uninitialized' false-positives. So this patch does two things:

 * Add -Wno-maybe-uninitialized to CFLAGS_UBSAN which will disable all
   such warnings for instrumented files.

 * Remove CONFIG_UBSAN_SANITIZE_ALL from all[yes|mod]config builds. So
   the all[yes|mod]config build goes without -fsanitize=* and still with
   -Wmaybe-uninitialized.

Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[backport from mainline for UBSAN]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Ia32d029540fcb5ebd19a3ac447a3b6333a173f84

arm64: ubsan: select ARCH_HAS_UBSAN_SANITIZE_ALL

To enable UBSAN on arm64, ARCH_HAS_UBSAN_SANITIZE_ALL need to be selected.

Basic kernel bootup test is passed on arm64 with CONFIG_UBSAN_SANITIZE_ALL
enabled.

Signed-off-by: Yang Shi <yang.shi@linaro.org>
Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
[backport from mainline for UBSAN]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I1876783c89adf8c7f0328434ab41c556440b64ff

ubsan: cosmetic fix to Kconfig text

When enabling UBSAN_SANITIZE_ALL, the kernel image size gets increased
significantly (~3x).  So, it sounds better to have some note in Kconfig.

And, fixed a typo.

Signed-off-by: Yang Shi <yang.shi@linaro.org>
Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[backport from mainline for UBSAN]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Ibd4183436723b1cad45eab0ffa5b0a8910edc0e6

UBSAN: run-time undefined behavior sanity checker

UBSAN uses compile-time instrumentation to catch undefined behavior
(UB).  Compiler inserts code that perform certain kinds of checks before
operations that could cause UB.  If check fails (i.e.  UB detected)
__ubsan_handle_* function called to print error message.

So the most of the work is done by compiler.  This patch just implements
ubsan handlers printing errors.

GCC has this capability since 4.9.x [1] (see -fsanitize=undefined
option and its suboptions).
However GCC 5.x has more checkers implemented [2].
Article [3] has a bit more details about UBSAN in the GCC.

[1] - https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/Debugging-Options.html
[2] - https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
[3] - http://developerblog.redhat.com/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/

Issues which UBSAN has found thus far are:

Found bugs:

 * out-of-bounds access - 97840cb67ff5 ("netfilter: nfnetlink: fix
   insufficient validation in nfnetlink_bind")

undefined shifts:

 * d48458d4a768 ("jbd2: use a better hash function for the revoke
   table")

 * 10632008b9e1 ("clockevents: Prevent shift out of bounds")

 * 'x << -1' shift in ext4 -
   http://lkml.kernel.org/r/<5444EF21.8020501@samsung.com>

 * undefined rol32(0) -
   http://lkml.kernel.org/r/<1449198241-20654-1-git-send-email-sasha.levin@oracle.com>

 * undefined dirty_ratelimit calculation -
   http://lkml.kernel.org/r/<566594E2.3050306@odin.com>

 * undefined roundown_pow_of_two(0) -
   http://lkml.kernel.org/r/<1449156616-11474-1-git-send-email-sasha.levin@oracle.com>

 * [WONTFIX] undefined shift in __bpf_prog_run -
   http://lkml.kernel.org/r/<CACT4Y+ZxoR3UjLgcNdUm4fECLMx2VdtfrENMtRRCdgHB2n0bJA@mail.gmail.com>

   WONTFIX here because it should be fixed in bpf program, not in kernel.

signed overflows:

 * 32a8df4e0b33f ("sched: Fix odd values in effective_load()
   calculations")

 * mul overflow in ntp -
   http://lkml.kernel.org/r/<1449175608-1146-1-git-send-email-sasha.levin@oracle.com>

 * incorrect conversion into rtc_time in rtc_time64_to_tm() -
   http://lkml.kernel.org/r/<1449187944-11730-1-git-send-email-sasha.levin@oracle.com>

 * unvalidated timespec in io_getevents() -
   http://lkml.kernel.org/r/<CACT4Y+bBxVYLQ6LtOKrKtnLthqLHcw-BMp3aqP3mjdAvr9FULQ@mail.gmail.com>

 * [NOTABUG] signed overflow in ktime_add_safe() -
   http://lkml.kernel.org/r/<CACT4Y+aJ4muRnWxsUe1CMnA6P8nooO33kwG-c8YZg=0Xc8rJqw@mail.gmail.com>

[akpm@linux-foundation.org: fix unused local warning]
[akpm@linux-foundation.org: fix __int128 build woes]
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sasha Levin <sasha.levin@oracle.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Yury Gribov <y.gribov@samsung.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Konstantin Khlebnikov <koct9i@gmail.com>
Cc: Kostya Serebryany <kcc@google.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[backport from mainline for UBSAN]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I216cb2d9dbfd9fc9e70b8e4515a0e34fcb68822f

kernel: printk: specify alignment for struct printk_log

On architectures that have support for efficient unaligned access struct
printk_log has 4-byte alignment.  Specify alignment attribute in type
declaration.

The whole point of this patch is to fix deadlock which happening when
UBSAN detects unaligned access in printk() thus UBSAN recursively calls
printk() with logbuf_lock held by top printk() call.

Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sasha Levin <sasha.levin@oracle.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Yury Gribov <y.gribov@samsung.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Konstantin Khlebnikov <koct9i@gmail.com>
Cc: Kostya Serebryany <kcc@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[Backport from mainline for UBSAN]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I93d23dec2c1539faf21eb7242ccc328999950c01

ARM64: configs: remove kasan defconfig

This patch removes tizen_tm2_kasan_defconfig which can be easily
made from tizen_tm2_defconfig.

Change-Id: I4bbc32f4147ab51768e5cd07e215e9d6d1616b2b
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

input: touchscreen: fts: fix to use touch_id with proper event_id only

From event handler, touch_id is used as index of array, but in can
be larger than array size, and it causes out of range access for
array. From event data of the fts hw, finger touch_id is only valid
when event_id is enter/leave/motion pointer event. So this patch
fixes to use touch_id as a array index only when the proper event_id
is received.

This issue is found by ubsan checker like following:

   ================================================================================
   UBSAN: Undefined behaviour in drivers/input/touchscreen/fts_ts.c:342:15
   index 13 is out of range for type 'fts_finger [10]'
   CPU: 1 PID: 98 Comm: irq/150-fts_tou Not tainted 4.1.0-01159-gfb62846 #17
   Hardware name: Samsung TM2 board (DT)
   Call trace:
   [<ffffffc00008f440>] dump_backtrace+0x0/0x218
   [<ffffffc00008f668>] show_stack+0x10/0x20
   [<ffffffc00159f378>] dump_stack+0x80/0xfc
   [<ffffffc00159f518>] ubsan_epilogue+0x10/0x6c
   [<ffffffc00159fef4>] __ubsan_handle_out_of_bounds+0xc8/0xf4
   [<ffffffc000ceb980>] fts_interrupt_handler+0x570/0x678
   [<ffffffc000165a98>] irq_thread+0x218/0x378
   [<ffffffc0000ee30c>] kthread+0x194/0x240
   ================================================================================

Change-Id: I3b2195ee0eee39b16cd05552c19c26072706125d
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

drm/panel: s6e3ha2: add VR mode support

This patch adds VR mode support.

For this, it creates a new sysfs file which is used by user-space
to enable or disable VR mode like below,

To enable,
echo 1 > /sys/devices/platform/soc/13900000.dsi/13900000.dsi.0/vr

To disable,
echo 0 > /sys/devices/platform/soc/13900000.dsi/13900000.dsi.0/vr

Actually, this patch enables mDNIe feature of Panel device and
updates its Display color temperature to 6500K for VR mode.

Change-Id: I4e9f15134f57fa200e63ac8fa9d94c5300d6a340
Signed-off-by: Inki Dae <inki.dae@samsung.com>