Functions which the compiler has instrumented for KASAN place poison on
the stack shadow upon entry and remove this poision prior to returning.
In the case of CPU hotplug, CPUs exit the kernel a number of levels deep
in C code. Any instrumented functions on this critical path will leave
portions of the stack shadow poisoned.
When a CPU is subsequently brought back into the kernel via a different
path, depending on stackframe, layout calls to instrumented functions
may hit this stale poison, resulting in (spurious) KASAN splats to the
console.
To avoid this, clear any stale poison from the idle thread for a CPU
prior to bringing a CPU online.
Change-Id: Idd24e933ce0a93b500d17de8262afe6e43d565c8
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Cc: Alexander Potapenko <glider@google.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
(cherry picked from commit e1b77c9298)
Functions which the compiler has instrumented for ASAN place poison on
the stack shadow upon entry and remove this poison prior to returning.
In some cases (e.g. hotplug and idle), CPUs may exit the kernel a
number of levels deep in C code. If there are any instrumented
functions on this critical path, these will leave portions of the idle
thread stack shadow poisoned.
If a CPU returns to the kernel via a different path (e.g. a cold
entry), then depending on stack frame layout subsequent calls to
instrumented functions may use regions of the stack with stale poison,
resulting in (spurious) KASAN splats to the console.
Contemporary GCCs always add stack shadow poisoning when ASAN is
enabled, even when asked to not instrument a function [1], so we can't
simply annotate functions on the critical path to avoid poisoning.
Instead, this series explicitly removes any stale poison before it can
be hit. In the common hotplug case we clear the entire stack shadow in
common code, before a CPU is brought online.
On architectures which perform a cold return as part of cpu idle may
retain an architecture-specific amount of stack contents. To retain the
poison for this retained context, the arch code must call the core KASAN
code, passing a "watermark" stack pointer value beyond which shadow will
be cleared. Architectures which don't perform a cold return as part of
idle do not need any additional code.
This patch (of 3):
Functions which the compiler has instrumented for KASAN place poison on
the stack shadow upon entry and remove this poision prior to returning.
In some cases (e.g. hotplug and idle), CPUs may exit the kernel a number
of levels deep in C code. If there are any instrumented functions on this
critical path, these will leave portions of the stack shadow poisoned.
If a CPU returns to the kernel via a different path (e.g. a cold entry),
then depending on stack frame layout subsequent calls to instrumented
functions may use regions of the stack with stale poison, resulting in
(spurious) KASAN splats to the console.
To avoid this, we must clear stale poison from the stack prior to
instrumented functions being called. This patch adds functions to the
KASAN core for removing poison from (portions of) a task's stack. These
will be used by subsequent patches to avoid problems with hotplug and
idle.
Change-Id: I0cfdd3ece4cb59876292f5ba1cadcdbda19de758
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
(cherry picked from commit e3ae116339)
In the case u2phy control vbus, the driver of usb controller
must control the vbus through the interface of u2phy, this
patch change the mode of u2phy when change dr_mode.
Change-Id: I8447bffc55e3502bf53a2e8af841a74914571781
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>
This patch supported the gpu opp table for rk3036.
The gpu clock's parent is DPLL, the default frequency is 400MHz, we need
assign 400MHz for gpu to be better working.
There is a quickly way for testing the gpu scaling frequency.
As following:
"
unset FREQS
read -a FREQS < /sys/class/devfreq/10091000.gpu/available_frequencies
RANDOM=$$$(date +%s)
while true; do
echo userspace > /sys/class/devfreq/10091000.gpu/governor
FREQ=${FREQS[$RANDOM % ${#FREQS[@]} ]}
echo GPU:Now ${FREQ}
echo ${FREQ} > /sys/class/devfreq/10091000.gpu/userspace/set_freq
sleep 1
done
"
Change-Id: Ia8eb3074e457014c497338a0a129551c51450104
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
As the gpu driver used the devfreq thermal, The mali will be failure to
load the driver since the rk platform hadn't the driver requested
deferred probing.
as the following is failure log:
[ 7.126149] Mali: ERR: drivers/gpu/arm/mali400/mali/linux/mali_kernel_linux.c
[ 7.126157] mali_probe() 550
mali_probe(): Failed to initialize platform device.
[ 7.126191] mali-utgard: probe of 10091000.gpu failed with error -14
..
Add the SoCs judge if we will use the devfreq-thermal for mali driver.
If the other SoCs has the similar issue, we can do this way.
Change-Id: I9faf6530119adb99efeac491e665641ee8b1143d
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
This commit adds a compatible string for everest,es8388. This is
an audio codec that is compatible with es8328.
Signed-off-by: Romain Perier <romain.perier@collabora.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 5f166156db)
Change-Id: I526239c3f4062849f2c96a610cf261f0f0de7aa4
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Instead of letting drivers fill in device_caps at querycap time,
let them fill it in when the video device is registered.
This has the advantage that in the future the v4l2 core can access
the video device's capabilities and take decisions based on that.
(am from 7bbe781329)
Change-Id: I2cc64fc2e562f7def0bea07c9b53a39ba4d772c3
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
This driver is modified from an old soc_camera driver.
It's kind of rough.
Change-Id: Ifb2656c5398277ace6902771128637f5dfd68061
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
The V4L2_BUF_TYPE_META_OUTPUT mirrors the V4L2_BUF_TYPE_META_CAPTURE with
the exception that it is an OUTPUT type. The use case for this is to pass
buffers to the device that are not image data but metadata. The formats,
just as the metadata capture formats, are typically device specific and
highly structured.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
(am from https://patchwork.linuxtv.org/patch/43308/)
Conflicts:
drivers/media/v4l2-core/v4l2-ioctl.c
include/media/v4l2-ioctl.h
BUG=b:66317170
TEST=compile
Change-Id: I86495fe82bf8dbddbc40f0ee1eb8e21145f427d3
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/676768
Reviewed-by: Ricky Liang <jcliang@chromium.org>
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
The metadata buffer type is used to transfer metadata between userspace
and kernelspace through a V4L2 buffers queue. It comes with a new
metadata capture capability and format description.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Guennadi Liakhovetski <guennadi.liakhovetski@intel.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
[hans.verkuil@cisco.com: removed left-over 'experimental' note]
[hans.verkuil@cisco.com: add newline after _v4l2-meta-format label]
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit fb9ffa6a7f)
Conflicts:
Documentation/media/uapi/v4l/buffer.rst
Documentation/media/uapi/v4l/devices.rst
Documentation/media/uapi/v4l/vidioc-querycap.rst
Documentation/media/videodev2.h.rst.exceptions
drivers/media/v4l2-core/v4l2-dev.c
drivers/media/v4l2-core/videobuf2-v4l2.c
include/media/v4l2-ioctl.h
Deleted the documentation, as 4.4 is before the conversion to rst.
BUG=b:66317170
TEST=compile
Change-Id: Id43757c0a0b1f34e10d17e5345f89ded25503d13
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/676767
Reviewed-by: Ricky Liang <jcliang@chromium.org>
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
The formats use three planes through the multiplanar API, allowing for
non-contiguous planes in memory.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
(cherry picked from commit d65fae92f9)
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chrome-os-partner:60805
TEST=build chromeos-4.4 for elm and boot
TEST=build chromeos-4.4 for kevin and boot
BUG=chrome-os-partner:43703
TEST=Compiled and tested on Elm.
Signed-off-by: Ricky Liang <jcliang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/420108
Reviewed-by: Wu-cheng Li <wuchengli@chromium.org>
Change-Id: I12fd0f0dc41325867777ae3723331926d5150d20
Reviewed-on: https://chromium-review.googlesource.com/424021
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
The vbus may need control by u2phy when force. This patch
control vbus when set phy mode.
Change-Id: I237e9e3688b257689c79040f19642cea5365d409
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>
1.Change rga1 driver to use dma API.
2.Fixup problem: version error.
Change-Id: Ibe8ac78927ec3b00e857c9c1e3c7321e418ede31
Signed-off-by: Putin Lee <putin.li@rock-chips.com>
Most of rockchip SoCs USB 2.0 DP/DM can be bypassed to UART,
it's useful for those platforms without UART interface to
print log via USB interface.
For the time being, we just support for rk312x and rk3399 in
this driver. And we will support for more SoCs in the feature.
With this patch, the user still can't use this bypass function.
It needs to add the property "rockchip,bypass-uart" in the DT
as following:
u2phy0_otg: otg-port {
...
rockchip,bypass-uart;
...
};
And it also needs a special USB cable integrated with an USB
to UART chip.
Note: this function can only be used in debug stage.
Change-Id: Icdab516ff7b327f4a98c3b24bbaf953a605f5278
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
add power and qos node to support power domain on/off.
Change-Id: I35088bfa7be407d7c627e32a84f2aafd1853e2df
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
This driver is modified to support RK3128 SoC.
Change-Id: Ica063ae432fe5bdc1d4eb10d0749fcf039f43d35
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Add binding documentation for the power domains
found on Rockchip RK3128 SoCs.
Change-Id: I8ca00fdf19bfcf354355eafd814f049b46533fd6
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
According to a description from TRM, add all the power domains.
Change-Id: Id21e1b51825f7cc94e194e164583ed2584743104
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
This patch supported the cpu voltage by changed with different
frequency, otherwise we will hit the following error on bootup.
..
[ 5.031516] cpu cpu0: Failed to get cpu_reg
[ 5.047725] cpu cpu0: clk or regulater is unavailable
..
Also, remove the 408M and 600M for rk3036 board, as the pclk_hdmi's parent
on apll, the low frequency will make the pclk be bad for hdmi display.
Change-Id: Ia4aac76a08cad3a59c33cd81065f943201a23a35
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
HDR source metadata set and get property implemented in this
patch. The blob data is received from userspace and saved in
connector state, the same is returned as blob in get property
call to userspace.
Change-Id: Iafde7d4d4a9567d54b283d8387d841e42d7b5b24
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
(am from list https://patchwork.kernel.org/patch/9756449/)
The hdr_panel_metadata indicate sink HDR capability，moving
it to drm_hdmi_info is more reasonable.
Change-Id: I0ccd404cfb0ec1e74130b0692de4261ae9a24c8f
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
HDR metadata block is introduced in CEA-861.3 spec.
Parsing the same to get the panel's HDR metadata.
Change-Id: I4cede936aa4d0ff844fa8abf24cb76211c785d53
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9756421/)
Enable Dynamic Range and Mastering Infoframe for HDR
content, which is defined in CEA 861.3 spec.
The metadata will be computed based on blending
policy in userspace compositors and passed as a connector
property blob to driver. The same will be sent as infoframe
to panel which support HDR.
Change-Id: I8025c3dba43dc5bb614115ede7841fe89d9f4d0b
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9756447/)
This patch adds a blob property to get HDR metadata
information from userspace. This will be send as part
of AVI Infoframe to panel.
Change-Id: I0d009889ca567213a5e264d74b6816ba6d2ee0d4
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9756427/)
CEA 861.3 spec adds colorimetry data block for HDMI.
Parsing the block to get the colorimetry data from
panel.
Change-Id: I7067bdec0dde52bc0e83d3cd30e6a674020823ad
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9756433/)
Add bit field and macro for extended tag in CEA block. Also,
declare macros for HDR metadata block.
Change-Id: I8169bc6605d7b2c718436f8cce1b8cb3932cd780
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9756419/)
This patch fixes the BT power reported the failure message.
As following:
root@linaro-alip:~# echo 1 > /sys/class/rfkill/rfkill0/state
[ 892.558269] rockchip-pinctrl pinctrl: pin gpio0-19 already requested
by 20060000.serial; cannot claim for wireless-bluetooth
[ 892.571052] rockchip-pinctrl pinctrl: pin-19 (wireless-bluetooth) status -22
...
And for now, the BT can work with this patch.
root@linaro-alip:~# echo 1 > /sys/class/rfkill/rfkill0/state
[ 69.328768] [BT_RFKILL]: ENABLE UART_RTS
[ 69.438540] [BT_RFKILL]: DISABLE UART_RTS
[ 69.443117] [BT_RFKILL]: bt turn on power
...
root@linaro-alip:~# hcitool dev
Devices:
hci0 94:A1:A2:E9:2D:18
And
root@linaro-alip:~# bluetoothctl
[NEW] Controller 94:A1:A2:E9:2D:18 linaro-alip [default]
[bluetooth]# scan on
Discovery started
[CHG] Controller 94:A1:A2:E9:2D:18 Discovering: yes
..
Change-Id: I2148f4203300ab4265fd3ba718f0d3ec0c57e7ca
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
select CFG80211 and MAC80211 when CONFIG_WIFI_BUILD_MODULE is set
Change-Id: I42acf5d554223b13c0c689b8edae15b4a7a57a70
Signed-off-by: Alex Zhao <zzc@rock-chips.com>
