https://source.android.com/security/bulletin/2021-02-01
CVE-2017-18509
CVE-2020-10767
* tag 'ASB-2021-02-05_4.19-stable': (809 commits)
ANDROID: GKI: fix up abi issues with 4.19.172
Linux 4.19.172
fs: fix lazytime expiration handling in __writeback_single_inode()
writeback: Drop I_DIRTY_TIME_EXPIRE
dm integrity: conditionally disable "recalculate" feature
tools: Factor HOSTCC, HOSTLD, HOSTAR definitions
tracing: Fix race in trace_open and buffer resize call
HID: wacom: Correct NULL dereference on AES pen proximity
futex: Handle faults correctly for PI futexes
futex: Simplify fixup_pi_state_owner()
futex: Use pi_state_update_owner() in put_pi_state()
rtmutex: Remove unused argument from rt_mutex_proxy_unlock()
futex: Provide and use pi_state_update_owner()
futex: Replace pointless printk in fixup_owner()
futex: Ensure the correct return value from futex_lock_pi()
futex: Prevent exit livelock
futex: Provide distinct return value when owner is exiting
futex: Add mutex around futex exit
futex: Provide state handling for exec() as well
futex: Sanitize exit state handling
...
Change-Id: Ieba6ee3a91a05d504e1f829a84e7d364e7d983f2
Conflicts:
arch/arm64/boot/dts/rockchip/rk3328.dtsi
drivers/md/Kconfig
drivers/usb/gadget/function/f_uac2.c
if pixels large than default which set in dtsi, use advanced-rates.
otherwise, use normal-rages.
Change-Id: I488c2815dbe1e3decd1d305a78bf523d944d1e96
Signed-off-by: Ding Wei <leo.ding@rock-chips.com>
method: when meets large resolution, higher clocks will be set.
if pixels less default_max_load, clocks use normal-rates setting.
otherwise, use advanced-rates instead.
Change-Id: I7e3c21903f02e3dbc7f84ea8084610ac76738c27
Signed-off-by: Ding Wei <leo.ding@rock-chips.com>
when cnt is more than codec_info size, then it may be overflow risk.
Change-Id: I7352118f425ccf263df0083c21ef0433f2322a43
Signed-off-by: Ding Wei <leo.ding@rock-chips.com>
when have task in running_list, it should be power off later.
Change-Id: I6df2d8ed11a05eba5753d78800c2175fc99ad0f1
Signed-off-by: Ding Wei <leo.ding@rock-chips.com>
1. Because of hw problems before, there will be problems with
high-frequency reset. So the frequency must be reduced before reset.
But this operation is unnecessary for now.
2. Iep share clk with rga on rk356x, so frequency reduction may affect rga.
Signed-off-by: Yandong Lin <yandong.lin@rock-chips.com>
Change-Id: I469d2d6ba2671560acd9eaf6b86d57411c7e3de5
Rootcause:
When hw detect there are more than eight rolling subtitles, it will
trigger a osd max irq but it still running, and that interruption make
the software takes for frame done and disable the clock gate, finally hw
hang when it access the bus.
Solution:
Ignore OSD MAX irq, clean and wait for frame done.
Signed-off-by: Yandong Lin <yandong.lin@rock-chips.com>
Change-Id: I660cefa013fe1419f7566b984556ea3450fe28e5
tips:
in rk3328, avsd and vdpu share the same interrupt number,
so, when each one hardware done, avsd and vdpu irq will response.
this is a normal log when meet the case.
Change-Id: I9fea220a64d7310805194d9f71c24db0cef1491e
Signed-off-by: Ding Wei <leo.ding@rock-chips.com>
1. Fix that when fd is used in A+B->C mode, the fd of
pat is not release.
2. Modify that the pat import from the application is
only copy to pat or src1.
Signed-off-by: Yu Qiaowei <cerf.yu@rock-chips.com>
Change-Id: I360459ba85fdaad5536a3317b5f415298be87d6b
Fixed the error that color fill would cause "req argument is inval".
Signed-off-by: Yu Qiaowei <cerf.yu@rock-chips.com>
Change-Id: I94ebfc2061f16916813a0d85630f8a9862728b0e
Because update_patten_buff_mode is not currently used,
it is removed.
Signed-off-by: Yu Qiaowei <cerf.yu@rock-chips.com>
Change-Id: I48c97e75d27d475eee528ed6c838c67fdaa430f8
When get dte_addr for iommu, it must enable reference clock.
Change-Id: Iaec423345463e001b2a7099067ab1e4a2d971f7f
Signed-off-by: Ding Wei <leo.ding@rock-chips.com>
tips:
1. rcb_size == 0, skip it.
2. if current rcb_size is larger then the remaining buffer size,
skip it instead of break.
Change-Id: Ide37ccbf0af9ceb3f4a6f6fe5e7045bfbd8ddc74
Signed-off-by: Ding Wei <leo.ding@rock-chips.com>
db49200b1dad is backported from the mainline commit
5f1251a48c ("video: hyperv_fb: Fix the cache type when mapping the VRAM"),
to v5.4.y and older stable branches, but unluckily db49200b1dad causes
mmap() to fail for /dev/fb0 due to EINVAL:
[ 5797.049560] x86/PAT: a.out:1910 map pfn expected mapping type
uncached-minus for [mem 0xf8200000-0xf85cbfff], got write-back
This means the v5.4.y kernel detects an incompatibility issue about the
mapping type of the VRAM: db49200b1dad changes to use Write-Back when
mapping the VRAM, while the mmap() syscall tries to use Uncached-minus.
That’s to say, the kernel thinks Uncached-minus is incompatible with
Write-Back: see drivers/video/fbdev/core/fbmem.c: fb_mmap() ->
vm_iomap_memory() -> io_remap_pfn_range() -> ... -> track_pfn_remap() ->
reserve_pfn_range().
Note: any v5.5 and newer kernel doesn't have the issue, because they
have commit
d21987d709 ("video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver")
, and when the hyperv_fb driver has the deferred_io support,
fb_deferred_io_init() overrides info->fbops->fb_mmap with
fb_deferred_io_mmap(), which doesn’t check the mapping type
incompatibility. Note: since it's VRAM here, the checking is not really
necessary.
Fix the regression by ioremap_wc(), which uses Write-combining. The kernel
thinks it's compatible with Uncached-minus. The VRAM mappped by
ioremap_wc() is slightly slower than mapped by ioremap_cache(), but is
still significantly faster than by ioremap().
Change the comment accordingly. Linux VM on ARM64 Hyper-V is still not
working in the latest mainline yet, and when it works in future, the ARM64
support is unlikely to be backported to v5.4 and older, so using
ioremap_wc() in v5.4 and older should be ok.
Note: this fix is only targeted at the stable branches:
v5.4.y, v4.19.y, v4.14.y, v4.9.y and v4.4.y.
Fixes: db49200b1dad ("video: hyperv_fb: Fix the cache type when mapping the VRAM")
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit ba236455ee ]
If devm_kzalloc() failed after the first time, atmel_lcdfb_of_init()
can't return -ENOMEM, fix this by putting the error code in loop.
Fixes: b985172b32 ("video: atmel_lcdfb: add device tree suport")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20201117061350.3453742-1-yangyingliang@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tips: The sel val read via VAL0_BASE VAL1_BASE VAL2_BASE.
Change-Id: Ida4eee44f4e4cd6a51ca81eeb28e39091433edf2
Signed-off-by: Ding Wei <leo.ding@rock-chips.com>
1. Support colorkey.
2. Support blend mode to restore real color.
Signed-off-by: Yu Qiaowei <cerf.yu@rock-chips.com>
Change-Id: I8eb6e60d4b9d3c5b6cc280e33edb9f0f3f08f2e2
[ Upstream commit 5f1251a48c ]
x86 Hyper-V used to essentially always overwrite the effective cache type
of guest memory accesses to WB. This was problematic in cases where there
is a physical device assigned to the VM, since that often requires that
the VM should have control over cache types. Thus, on newer Hyper-V since
2018, Hyper-V always honors the VM's cache type, but unexpectedly Linux VM
users start to complain that Linux VM's VRAM becomes very slow, and it
turns out that Linux VM should not map the VRAM uncacheable by ioremap().
Fix this slowness issue by using ioremap_cache().
On ARM64, ioremap_cache() is also required as the host also maps the VRAM
cacheable, otherwise VM Connect can't display properly with ioremap() or
ioremap_wc().
With this change, the VRAM on new Hyper-V is as fast as regular RAM, so
it's no longer necessary to use the hacks we added to mitigate the
slowness, i.e. we no longer need to allocate physical memory and use
it to back up the VRAM in Generation-1 VM, and we also no longer need to
allocate physical memory to back up the framebuffer in a Generation-2 VM
and copy the framebuffer to the real VRAM. A further big change will
address these for v5.11.
Fixes: 68a2d20b79 ("drivers/video: add Hyper-V Synthetic Video Frame Buffer Driver")
Tested-by: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Link: https://lore.kernel.org/r/20201118000305.24797-1-decui@microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
The userspace librga(im2d) is using 0x16 for BGRX8888.
Signed-off-by: Yu Qiaowei <cerf.yu@rock-chips.com>
Change-Id: I6cac09898039aefa87f5633d60bf590e3f130e56
1. Add hardware register dump function.
2. Dump irq_status on error when debug flag is set.
Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
Change-Id: Iad4f4af98756e02438d82b231b53b4eefb0bd632
CONFIG_PM_DEVFREQ enable, while devfreq is not set in dtsi.
then freq is not actually set.
Change-Id: Ie615d38393155c0c0debdc4522f1d47869ea15a2
Signed-off-by: Ding Wei <leo.ding@rock-chips.com>
1. Add x mirror + y mirror mode.
2. Support rotation and mirror configuration at the
same time.
Signed-off-by: Yu Qiaowei <cerf.yu@rock-chips.com>
Change-Id: If958e620633e17101495631acf3751a67953b19f
[ Upstream commit 8e1ba47c60 ]
clang static analysis reports this repesentative error
pvr2fb.c:1049:2: warning: 1st function call argument
is an uninitialized value [core.CallAndMessage]
if (*cable_arg)
^~~~~~~~~~~~~~~
Problem is that cable_arg depends on the input loop to
set the cable_arg[0]. If it does not, then some random
value from the stack is used.
A similar problem exists for output_arg.
So initialize cable_arg and output_arg.
Signed-off-by: Tom Rix <trix@redhat.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200720191845.20115-1-trix@redhat.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
when iommu pagefault, mark_irq to disable iommu interrupt,
then handle the fault, and unmark_irq to enable hardware.
Change-Id: Id40868bfab67ac27e12c181d83a8e70a09a1e498
Signed-off-by: Ding Wei <leo.ding@rock-chips.com>
[ Upstream commit fe6c6a4af2 ]
When radeon_kick_out_firmware_fb() fails, info should be
freed just like the subsequent error paths.
Fixes: 069ee21a82 ("fbdev: Fix loading of module radeonfb on PowerMac")
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
Reviewed-by: Mathieu Malaterre <malat@debian.org>
Cc: Kangjie Lu <kjlu@umn.edu>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200825062900.11210-1-dinghao.liu@zju.edu.cn
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit ad6f93e9cd ]
Clang static analysis reports this representative error
init.c:2501:18: warning: Array access (from variable 'queuedata') results
in a null pointer dereference
templ |= ((queuedata[i] & 0xc0) << 3);
This is the problem block of code
if(ModeNo > 0x13) {
...
if(SiS_Pr->ChipType == SIS_730) {
queuedata = &FQBQData730[0];
} else {
queuedata = &FQBQData[0];
}
} else {
}
queuedata is not set in the else block
Reviewing the old code, the arrays FQBQData730 and FQBQData were
used directly.
So hoist the setting of queuedata out of the if-else block.
Fixes: 544393fe58 ("[PATCH] sisfb update")
Signed-off-by: Tom Rix <trix@redhat.com>
Cc: Thomas Winischhofer <thomas@winischhofer.net>
Cc: Andrew Morton <akpm@osdl.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200805145208.17727-1-trix@redhat.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit c72fab81ce ]
The pixclock is being set locally because it is being passed as a
pass-by-value argument rather than pass-by-reference, so the computed
pixclock is never being set in var->pixclock. Fix this by passing
by reference.
[This dates back to 2002, I found the offending commit from the git
history git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git ]
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@intel.com>
[b.zolnierkie: minor patch summary fixup]
[b.zolnierkie: removed "Fixes:" tag (not in upstream tree)]
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200723170227.996229-1-colin.king@canonical.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
