Add symbol list for Lenovo
1 function symbol added
'rebuild_sched_domains()'
Bug: 286015587
Change-Id: I35fe23cc6314fb6b7bf564f0fd749141f4c33752
Signed-off-by: vincent wang <vincentwang3@lenovo.com>
Vendor module needs to rebuild sched domains at boot, in the
event that cpufreq initializes the energy model too late.
Bug: 242898038
Change-Id: Ifaf1223366ac81c3f3c382dd0f61110fce9c1b20
Signed-off-by: Stephen Dickey <quic_dickey@quicinc.com>
(cherry picked from commit 20ba031cf8)
Adding the following symbols:
- snd_pcm_hw_constraint_integer
- snd_soc_set_runtime_hwparams
Bug: 264508873
Change-Id: I5616a0aa475456abdfb466d62c08accd5f8b222f
Signed-off-by: Robert Lee <lerobert@google.com>
PCIe r6.0, sec 5.9, requires a 10ms delay between programming a device to
change to or from D3hot and the time the device is next accessed (unless
Readiness Notifications are used).
The 10ms value (PCI_PM_D3HOT_WAIT) doesn't appear directly here because
some chipsets require 120ms for devices *below* them (pci_pm_d3hot_delay)
and some devices require more or less than 10ms (dev->d3hot_delay).
But msleep(10) typically waits about *20*ms, which is more than we need.
Switch to usleep_range() to improve the delay accuracy.
Based on a commit from Sajid in the Pixel 6 kernel tree [1]. On a Pixel 6,
the 10ms delay for the Exynos PCIe device delayed for an average of 19ms.
Switching to usleep_range() decreased the resume time by about 9ms.
[1] 18a8cad68d
[bhelgaas commit log, add timers-howto.rst link]
Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/timers/timers-howto.rst?id=v5.19#n73
Link: https://lore.kernel.org/r/20220921212735.2131588-1-willmcvicker@google.com
Signed-off-by: Sajid Dalvi <sdalvi@google.com>
Signed-off-by: Will McVicker <willmcvicker@google.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Bug: 258100247
Change-Id: Iacde62a3ec8e4b924a21fb654c89a18df2ee2b87
(cherry picked from commit 3e347969a5)
Signed-off-by: Sajid Dalvi <sdalvi@google.com>
Android 14 and later default to MGLRU [1] and field telemetry showed
occasional long tail latency (>100ms) in the reclaim path.
Tracing revealed priority inversion in the reclaim path. In
try_to_inc_max_seq(), when high priority tasks were blocked on
wait_event_killable(), the preemption of the low priority task to call
wake_up_all() caused those high priority tasks to wait longer than
necessary. In general, this problem is not different from others of its
kind, e.g., one caused by mutex_lock(). However, it is specific to MGLRU
because it introduced the new wait queue lruvec->mm_state.wait.
The purpose of this new wait queue is to avoid the thundering herd
problem. If many direct reclaimers rush into try_to_inc_max_seq(), only
one can succeed, i.e., the one to wake up the rest, and the rest who
failed might cause premature OOM kills if they do not wait. So far there
is no evidence supporting this scenario, based on how often the wait has
been hit. And this begs the question how useful the wait queue is in
practice.
Based on Minchan's recommendation, which is in line with his commit
6d4675e601 ("mm: don't be stuck to rmap lock on reclaim path") and the
rest of the MGLRU code which also uses trylock when possible, remove the
wait queue.
[1] https://android-review.googlesource.com/q/I7ed7fbfd6ef9ce10053347528125dd98c39e50bf
Link: https://lkml.kernel.org/r/20230413214326.2147568-1-kaleshsingh@google.com
Fixes: bd74fdaea1 ("mm: multi-gen LRU: support page table walks")
Change-Id: Ia2c65c92652018bb833e632028075ea27b68477e
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Suggested-by: Minchan Kim <minchan@kernel.org>
Reported-by: Wei Wang <wvw@google.com>
Acked-by: Yu Zhao <yuzhao@google.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Jan Alexander Steffens (heftig) <heftig@archlinux.org>
Cc: Oleksandr Natalenko <oleksandr@natalenko.name>
Cc: Suleiman Souhlal <suleiman@google.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 7f63cf2d9b)
Bug: 277906484
[ Kalesh Singh - Fix conflicts in mm/vmscan.c ]
[ Kalesh Singh - Fix up ABI breakages in include/linux/mmzone.h ]
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
On Android app cycle workloads, MGLRU showed a significant reduction in
workingset refaults although pgpgin/pswpin remained relatively unchanged.
This indicated MGLRU may be undercounting workingset refaults.
This has impact on userspace programs, like Android's LMKD, that monitor
workingset refault statistics to detect thrashing.
It was found that refaults were only accounted if the MGLRU shadow entry
was for a recently evicted folio. However, recently evicted folios should
be accounted as workingset activation, and refaults should be accounted
regardless of recency.
Fix MGLRU's workingset refault and activation accounting to more closely
match that of the conventional active/inactive LRU.
Link: https://lkml.kernel.org/r/20230523205922.3852731-1-kaleshsingh@google.com
Fixes: ac35a49023 ("mm: multi-gen LRU: minimal implementation")
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Reported-by: Charan Teja Kalla <quic_charante@quicinc.com>
Acked-by: Yu Zhao <yuzhao@google.com>
Cc: Brian Geffon <bgeffon@google.com>
Cc: Jan Alexander Steffens (heftig) <heftig@archlinux.org>
Cc: Oleksandr Natalenko <oleksandr@natalenko.name>
Cc: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 02ad728453d2ddb09d7ce5e59854ebb27544d488 https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-unstable)
Bug: 284043217
[ Kalesh Singh - Fix conflicts in mm/workingset.c ]
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Change-Id: I6d42cca9064e66099fbbc20aa2143961f84b2003
Disable CONFIG_ARM64_BTI_KERNEL since significant overhead has been observed
on systems that don't have BTI/PAC hardware support due to increased number
of NOPs added by these features.
BTI is not as important in kernels that have CFI enabled because the protection
these features offer overlap.
Keep PAC enabled and also enable dynamic SCS (CONFIG_UNWIND_PATCH_PAC_INTO_SCS)
which is available starting in v6.2. This removes SCS overhead on systems that
support PAC, and PAC overhead on systems that need SCS instead. This feature uses
runtime code patching, so it won't have the overhead of additional NOPs.
Bug: 267119345
Change-Id: Ifc7d5e502940bd15d13e7f89c5facd10b6c7b8a8
Signed-off-by: Todd Kjos <tkjos@google.com>
Implement dynamic shadow call stack support on Clang, by parsing the
unwind tables at init time to locate all occurrences of PACIASP/AUTIASP
instructions, and replacing them with the shadow call stack push and pop
instructions, respectively.
This is useful because the overhead of the shadow call stack is
difficult to justify on hardware that implements pointer authentication
(PAC), and given that the PAC instructions are executed as NOPs on
hardware that doesn't, we can just replace them without breaking
anything. As PACIASP/AUTIASP are guaranteed to be paired with respect to
manipulations of the return address, replacing them 1:1 with shadow call
stack pushes and pops is guaranteed to result in the desired behavior.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Tested-by: Sami Tolvanen <samitolvanen@google.com>
Link: https://lore.kernel.org/r/20221027155908.1940624-4-ardb@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit 3b619e22c4)
Bug: 283954062
Change-Id: Idca66f03315191a9fb18ed17d5b79c5bfacc51b8
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
In order to allow arches to use code patching to conditionally emit the
shadow stack pushes and pops, rather than always taking the performance
hit even on CPUs that implement alternatives such as stack pointer
authentication on arm64, add a Kconfig symbol that can be set by the
arch to omit the SCS codegen itself, without otherwise affecting how
support code for SCS and compiler options (for register reservation, for
instance) are emitted.
Also, add a static key and some plumbing to omit the allocation of
shadow call stack for dynamic SCS configurations if SCS is disabled at
runtime.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Tested-by: Sami Tolvanen <samitolvanen@google.com>
Link: https://lore.kernel.org/r/20221027155908.1940624-3-ardb@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit 9beccca098)
Bug: 283954062
Change-Id: I71ed23533124b071bd6bf5ab91b2af3bbf03b42b
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Enable asynchronous unwind table generation for both the core kernel as
well as modules, and emit the resulting .eh_frame sections as init code
so we can use the unwind directives for code patching at boot or module
load time.
This will be used by dynamic shadow call stack support, which will rely
on code patching rather than compiler codegen to emit the shadow call
stack push and pop instructions.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Tested-by: Sami Tolvanen <samitolvanen@google.com>
Link: https://lore.kernel.org/r/20221027155908.1940624-2-ardb@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit 68c76ad4a9)
Bug: 283954062
Change-Id: I2e17c7171295dc3859ff385b11a10048f6c87ec5
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Setting CONFIG_PM_ADVANCED_DEBUG=y to expose device async fields
to userspace, allowing to fine-tune the suspend/resume path.
Bug: 235135485
Change-Id: I75060e88ce0c1e199aa8740f446a2c0f8167f3d7
Signed-off-by: Vincent Palomares <paillon@google.com>
Instead of running the request queue of each device associated with a
host every 3 ms (BLK_MQ_RESOURCE_DELAY) while host error handling is in
progress, run the request queue after error handling has finished.
Bug: 280478861
Change-Id: Icd06853dc4868778bc7942d7fac6de71a7a80f71
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Make the SCSI sense data available in the ftrace output.
Bug: 275581839
Change-Id: I0fc87346effe71940a450d3a114365029d851b77
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Patch "block: mq-deadline: Handle requeued requests correctly" broke
support for zone sizes that are not a power of two. Restore support for
zone sizes that are not a power of two.
Bug: 275581839
Change-Id: I05d1b3253247f21583891502291e4a861bebb15e
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Make it easier to debug out-of-order zoned writes.
Bug: 275581839
Change-Id: I5d1f1cd47ff1b4c10788edeebba5e80bd82b2bf3
Signed-off-by: Bart Van Assche <bvanassche@google.com>
If a queue is run before all requeued requests have been sent to the I/O
scheduler, the I/O scheduler may dispatch the wrong request. Fix this by
making __blk_mq_run_hw_queue() process the requeue_list instead of
blk_mq_requeue_work().
Bug: 275581839
Change-Id: Id72c0787607f90857ae8e75998d532b96b46b8c2
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Requeue requests instead of sending these to the dispatch list if a CPU
is unplugged to prevent reordering of zoned writes.
Bug: 275581839
Change-Id: I2f03ba0832fc9609472c2bfa19d2cdd8abeffd8d
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Make sure that the I/O scheduler has control over which requests are
dispatched.
Bug: 275581839
Change-Id: If8c70df11584b023c452fbba28c67b092ddac850
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Send requests with the REQ_FUA or REQ_PREFLUSH flag set to the I/O
scheduler. Do not change the behavior for REQ_OP_FLUSH requests.
This patch prevents that zoned writes with the REQ_FUA and/or
REQ_PREFLUSH flag set are reordered against each other.
Bug: 275581839
Change-Id: Ib7f18932a066c40f5b76dc69c1864a080350251d
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Combine two return statements into a single return statement.
Bug: 275581839
Change-Id: I543e3dad88766157c0c334def4d525c10334e476
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Remove the 'hctx' argument because it is not used.
Bug: 275581839
Change-Id: I1f632931bc6c3d1ad89c4e6e93417c7301699559
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Set KMI_GENERATION=7 for 5/24 KMI update
type 'struct binder_transaction' changed
byte size changed from 176 to 192
member 'pid_t from_pid' was added
member 'pid_t from_tid' was added
13 members ('struct binder_transaction* from_parent' .. 'kuid_t sender_euid') changed
offset changed by 64
member 'ktime_t start_time' was added
4 members ('struct list_head fd_fixups' .. 'u64 android_vendor_data1') changed
offset changed by 128
Bug: 283322303
Change-Id: Ic9eaacc3707e86614dfb9fc6abde30ba722ed3bf
Signed-off-by: Carlos Llamas <cmllamas@google.com>
This commit adds support for getting the pid and tid information of
the sender for asynchronous transfers in binderfs transfer records.
In previous versions, it was not possible to obtain this information
from the transfer records. While this information may not be necessary
for all use cases, it can be useful in some scenarios.
Signed-off-by: Chuang Zhang <zhangchuang3@xiaomi.com>
Acked-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/0c1e8bd37c68dd1518bb737b06b768cde9659386.1682333709.git.zhangchuang3@xiaomi.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 235773151
(cherry picked from commit c21c0f9a20
git: //git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
char-misc-next)
Change-Id: I7e729853353522164c4a3dd1094145dfd19af961
Signed-off-by: Carlos Llamas <cmllamas@google.com>
This reverts commit ad2bd67e07.
Qualcomm is reporting that internal debugging tools in addition to
Lauterbach Trace32 (T32) debugger (vLT_20230509_159359) are having
issues with DWARFv5.
Since the change to the DWARF debug info format was made after the
Android Feature Complete deadline, revert it from android14-* kernel
branches. We'll leave DWARFv5 for android-mainline and try again next
release in android15-*.
Bug: 281863640
Reported-by: Satya Durga Srinivasu Prabhala <quic_satyap@quicinc.com>
Change-Id: I5a1657bdf6785d23f3492dc12e6f3df0954b8deb
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Modern interactive systems, such as recent Android phones, tend to have
power efficient shallow idle states. Selecting deeper idle states on a
device while a latency-sensitive workload is running can adversely
impact performance due to increased latency. Additionally, if the CPU
wakes up from a deeper sleep before its target residency as is often the
case, it results in a waste of energy on top of that.
At the moment, none of the available idle governors take any scheduling
information into account. They also tend to overestimate the idle
duration quite often, which causes them to select excessively deep idle
states, thus leading to increased wakeup latency and lower performance
with no power saving. For 'menu' while web browsing on Android for
instance, those types of wakeups ('too deep') account for over 24% of
all wakeups.
At the same time, on some platforms idle state 0 can be power efficient
enough to warrant wanting to prefer it over idle state 1. This is
because the power usage of the two states can be so close that
sufficient amounts of too deep state 1 sleeps can completely offset the
state 1 power saving to the point where it would've been more power
efficient to just use state 0 instead. This is, of course, for systems
where state 0 is not a polling state, such as arm-based devices.
Sleeps that happened in state 0 while they could have used state 1 ('too
shallow') only save less power than they otherwise could have. Too deep
sleeps, on the other hand, harm performance and nullify the potential
power saving from using state 1 in the first place. While taking this
into account, it is clear that on balance it is preferable for an idle
governor to have more too shallow sleeps instead of more too deep sleeps
on those kinds of platforms.
This patch specifically tunes TEO to prefer shallower idle states in
order to reduce wakeup latency and achieve better performance.
To this end, before selecting the next idle state it uses the avg_util
signal of a CPU's runqueue in order to determine to what extent the CPU
is being utilized. This util value is then compared to a threshold
defined as a percentage of the CPU's capacity (capacity >> 6 ie. ~1.5%
in the current implementation). If the util is above the threshold, the
index of the idle state selected by TEO metrics will be reduced by 1,
thus selecting a shallower state. If the util is below the threshold,
the governor defaults to the TEO metrics mechanism to try to select the
deepest available idle state based on the closest timer event and its
own correctness.
The main goal of this is to reduce latency and increase performance for
some workloads. Under some workloads it will result in an increase in
power usage (Geekbench 5) while for other workloads it will also result
in a decrease in power usage compared to TEO (PCMark Web, Jankbench,
Speedometer).
It can provide drastically decreased latency and performance benefits in
certain types of workloads that are sensitive to latency.
Example test results:
1. GB5 (better score, latency & more power usage)
| metric | menu | teo | teo-util-aware |
| ------------------------------------- | -------------- | ----------------- | ----------------- |
| gmean score | 2826.5 (0.0%) | 2764.8 (-2.18%) | 2865 (1.36%) |
| gmean power usage [mW] | 2551.4 (0.0%) | 2606.8 (2.17%) | 2722.3 (6.7%) |
| gmean too deep % | 14.99% | 9.65% | 4.02% |
| gmean too shallow % | 2.5% | 5.96% | 14.59% |
| gmean task wakeup latency (asynctask) | 78.16μs (0.0%) | 61.60μs (-21.19%) | 54.45μs (-30.34%) |
2. Jankbench (better score, latency & less power usage)
| metric | menu | teo | teo-util-aware |
| ------------------------------------- | -------------- | ----------------- | ----------------- |
| gmean frame duration | 13.9 (0.0%) | 14.7 (6.0%) | 12.6 (-9.0%) |
| gmean jank percentage | 1.5 (0.0%) | 2.1 (36.99%) | 1.3 (-17.37%) |
| gmean power usage [mW] | 144.6 (0.0%) | 136.9 (-5.27%) | 121.3 (-16.08%) |
| gmean too deep % | 26.00% | 11.00% | 2.54% |
| gmean too shallow % | 4.74% | 11.89% | 21.93% |
| gmean wakeup latency (RenderThread) | 139.5μs (0.0%) | 116.5μs (-16.49%) | 91.11μs (-34.7%) |
| gmean wakeup latency (surfaceflinger) | 124.0μs (0.0%) | 151.9μs (22.47%) | 87.65μs (-29.33%) |
Bug: 258723112
Change-Id: Ifea46051fb4b0554349aa50145130e38efa5f163
Signed-off-by: Kajetan Puchalski <kajetan.puchalski@arm.com>
[ rjw: Comment edits and white space adjustments ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 9ce0f7c4bc)
[Build error due to different signature of sched_cpu_util()]
Signed-off-by: Qais Yousef <qyousef@google.com>
Add a no_poll flag to teo_find_shallower_state() that will let the
function optionally not consider polling states.
This allows the caller to guard against the function inadvertently
resulting in TEO putting the CPU in a polling state when that
behaviour is undesirable.
Bug: 258723112
Change-Id: Ic3879fd4428dd4c7b19caaee6f9fd847cdb58483
Signed-off-by: Kajetan Puchalski <kajetan.puchalski@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 27f8508801)
Signed-off-by: Qais Yousef <qyousef@google.com>
We want to add more special values, specifically for uclamp_max so that
it can be set automatically to the most efficient value based on the
core it's running on.
Bug: 283761535
Signed-off-by: Qais Yousef <qyousef@google.com>
Change-Id: I57343c4544f6cac621c855cbb94de0b8d80c51fa
Kernel IOMMU drivers can report system misconfiguration through
pkvm_iommu_finalize().
Then EL2 can take the proper response, for example if there are missing
IOMMUs, and DMA isolation can't be ensured, it would clear pvmfw so
PVMs can't be launched.
However, this is not clean as userspace can still query pvmfw info
and launch PVMs that loops in undefined instruction aborts as pvmfw
is cleared.
To fix this, before deprivilege, the kernel will erase pvmfw if the
IOMMUs are not finalised.
Bug: 268607700
Test: Launch PVM with missing S2MPU => Fail immediately with -8
Test: Launch PVM with all S2MPU => Pass
Change-Id: I9fd2440805f6b2f2ad4395ce61df5b272ed84fef
Signed-off-by: Mostafa Saleh <smostafa@google.com>
Rename this function to align the function name with the function name
used in the upstream Linux kernel.
Bug: 275581839
Change-Id: I085ffacf535e65d8afbb9935a2cca26c4fec0d80
Signed-off-by: Bart Van Assche <bvanassche@google.com>
In bfq_pd_alloc(), the function bfqg_stats_init() init bfqg. If
blkg_rwstat_init() init bfqg_stats->bytes successful and init
bfqg_stats->ios failed, bfqg_stats_init() return failed, bfqg will
be freed. But blkg_rwstat->cpu_cnt is not deleted from the list of
percpu_counters. If we traverse the list of percpu_counters, It will
have UAF problem.
we should use blkg_rwstat_exit() to cleanup bfqg_stats bytes in the
above scenario.
Fixes: commit fd41e60331 ("bfq-iosched: stop using blkg->stat_bytes and ->stat_ios")
Change-Id: I133bae6a318a8ddc4f10a8ee8e63595a1219ea1e
Signed-off-by: Zheng Liang <zhengliang6@huawei.com>
Acked-by: Tejun Heo <tj@kernel.org>
Link: https://lore.kernel.org/r/20211018024225.1493938-1-zhengliang6@huawei.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit 2fc428f6b7)
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Logging callback symbolic name is generating too many different
messages making Abort analysis miss big trends.
Stick to console reported message providing sufficient information.
Bug: 280678242
Signed-off-by: Thierry Strudel <tstrudel@google.com>
(cherry picked from https://android-review.googlesource.com/q/commit:9f8f2ea03ede21d8928793c4be87eeb76d81bc7f)
Merged-In: Ic0ea662a60919454060e3a085aeabd8a4099e0b4
Change-Id: Ic0ea662a60919454060e3a085aeabd8a4099e0b4
For devices with no cache it can make sense to use cache only mode as a
mechanism for trapping writes to hardware which is inaccessible but since
no cache is equivalent to cache bypass we force such devices into bypass
mode. This means that our check that bypass and cache only mode aren't both
enabled simultanously is less sensible for devices without a cache so relax
it.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220622171723.1235749-1-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Bug: 274730214
Change-Id: I85f9ba5343f28b24c2b0588e8a1487d31b654283
(cherry picked from commit 3d0afe9cf1)
Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com>
(cherry picked from commit b099f1eb0b330487fcc77e8a991919608fd07189)
