This gerrit disables CONFIG_DEBUG_PANIC_ON_OOM in userdebug builds
(for cebu device). It prevents Kernel Panic generation when Kernel
memory allocation fails, due to an Out of Memory (OOM) detection.
As OOM condition isn't so unusual (specially for heavy users), it
won't be a good experience for users to face kernel panics everytime
this OOM condition is satisfied.
Reference gerrit: https://gerrit.mot.com/#/c/1732467/
Change-Id: I7c1d017daa1671eef9b723adb72391901a2aed27
Reviewed-on: https://gerrit.mot.com/1905120
SLTApproved: Slta Waiver
SME-Granted: SME Approvals Granted
Tested-by: Jira Key
Reviewed-by: Tiago Ganselli <ganselli@motorola.com>
Reviewed-by: Joo Costa <jmcosta@motorola.com>
Reviewed-by: Fernanda Schmidt <fschmidt@motorola.com>
Reviewed-by: Rafael Ortolan <rafones@motorola.com>
Reviewed-by: Carlos Pinho <cpinho@motorola.com>
Submit-Approved: Jira Key
Issue: At mot4250 android R is not supporting inline encryption
This causes recovery mode with init_user0_failed log
when upgrade from Q to R
Fix: Include inlinecrypt at fstab and config.gz
Change-Id: I2b20a7cbd3670e6b9bf5c9885a14a1b0e4ec2083
Reviewed-on: https://gerrit.mot.com/1896972
SME-Granted: SME Approvals Granted
SLTApproved: Slta Waiver
Tested-by: Jira Key
Reviewed-by: Ling Jin <lingjin@motorola.com>
Submit-Approved: Jira Key
PROPAGATED_from (CR)
Add device tree property xhci-hw-lpm-disable support for
xhci hardware lpm feature disabling.
For some connected devices the host phone, they may be some
detection issue if xhci hardware lpm feature is enabled.
For this case, add this property in device tree of usb controller
to disable xhci hardware lpm.
(pick from https://gerrit.mot.com/#/c/1426964/)
Change-Id: I3907c945dd83fdefdda597975318e45d8be047e1
Signed-off-by: yanyh2 <yanyh2@motorola.com>
SLTApproved: Slta Waiver
SME-Granted: SME Approvals Granted
Tested-by: Jira Key
Reviewed-by: Zonghua Liu <a17671@motorola.com>
Reviewed-by: Lu Chai <chailu1@motorola.com>
Reviewed-by: Yuecai Liu <liuyc20@motorola.com>
Reviewed-by: Huosheng Liao <liaohs@motorola.com>
Submit-Approved: Jira Key
Signed-off-by: Robert Cabral <robertc@motorola.com>
Reviewed-on: https://gerrit.mot.com/1858485
cherry-pick: (CR) kernel:ram overwritten by TZ logs to cause random panics
in panic RAMDump file, we can see the memory in kernel was overwritten by TZ logs
the tzlog strings corrupted the memory address to cause abort on VM to PHY-M
similar panic issue was frequently reported in User build which disable
DebugFS along with tzlog driver which depends on DebugFS. Add the tzlog driver
back, but remove the dependency of DebugFS, instead, use ProcFS for output
Change-Id: If6f9f0bf0fe3ce08c868582a457b207cee07923d
Signed-off-by: wangwang1 <wangwang1@lenovo.com>
Reviewed-on: https://gerrit.mot.com/1836697
SLTApproved: Slta Waiver
SME-Granted: SME Approvals Granted
Tested-by: Jira Key
Reviewed-by: Xiangpo Zhao <zhaoxp3@motorola.com>
Submit-Approved: Jira Key
Reviewed-on: https://gerrit.mot.com/1836767
Vibrator on phone main board can disturb camera AF VCM when it's vibrating.
To avoid the camera lens str(CR) noise during vibrating, power on AF and
push lens to certain position (for caprip DAC 154) can greatly reduce the
noise.This change is for notifying camera actuator that vibrator will start
or stop work, then camera can respond accordingly..
Change-Id: Ie26d6f811d6628f51045a853dc3e90f422481da9
Signed-off-by: huangdra <huangdra@motorola.com>
Reviewed-on: https://gerrit.mot.com/1836813
SLTApproved: Slta Waiver
SME-Granted: SME Approvals Granted
Tested-by: Jira Key
Reviewed-by: Xiangpo Zhao <zhaoxp3@motorola.com>
Submit-Approved: Jira Key
This is a workarround to reduce the vibrator strength for long vib.
Add attribute "qcom,vib-dis-short-long" in device-tree to enable the
function.
Now it is applied in caprip product.
Change-Id: I41c04e0dfb14c184f999d7d0a4121c10dd763cd5
Signed-off-by: panzh2 <panzh2@lenovo.com>
Reviewed-on: https://gerrit.mot.com/1805268
SLTApproved: Slta Waiver
SME-Granted: SME Approvals Granted
Tested-by: Jira Key
Reviewed-by: Wang Wang <wangwang1@lenovo.com>
Submit-Approved: Jira Key
We often see lost ram is still very high even we close the camera app.
That's because camera's ion memory goes into ion cache after use, not
buddy system. And this cache was not counted in proc/meminfo/memAvailable,
so it can not reflect the true memAvailable in this state. It may affects
some components l(CR) camera or lmkd which need evaluate true memAvailable
in system. Take camera as example, while launching camera, camera app needs
calcuate the available memory then call framework api to kill processes,
without this patch, we will see overkill.
This patch is only for 4.14 & 4.19, on kernel 5.4, ion cache will
be counted in memAvailable, so memAvailable is always trustable.
Change-Id: I4a9678530d387bd8da404d797f7d6e33bd258ac4
Signed-off-by: huangzq2 <huangzq2@motorola.com>
Reviewed-on: https://gerrit.mot.com/1792299
SLTApproved: Slta Waiver
SME-Granted: SME Approvals Granted
Tested-by: Jira Key
Reviewed-by: Xiangpo Zhao <zhaoxp3@motorola.com>
Submit-Approved: Jira Key
(cherry picked from commit a9acaa732c7fcb5e9ec9eea08bb6bb390c316722)
Reviewed-on: https://gerrit.mot.com/1795665
This reverts commit 3a7c2ddda918ea0ba239c51d74984a499c392942.
This change has been included in new base .so revert it
Change-Id: I50210a029c2f69b8561a7cae2f4b87b190b8a842
Reviewed-on: https://gerrit.mot.com/1791620
SME-Granted: SME Approvals Granted
SLTApproved: Slta Waiver
Submit-Approved: Jira Key
Tested-by: Jira Key
Reviewed-by: gaoyx9 <gaoyx9@motorola.com>
porting (CR)
1. Print active wakeup source before entering suspend
2. Use to monitor the kernel long term wake lock issue
Change-Id: Icee9744da0c46fbb56d516e996eed7115f754931
Signed-off-by: xieqiong2 <xieqiong2@lenovo.com>
Reviewed-on: https://gerrit.mot.com/1788058
SLTApproved: Slta Waiver
SME-Granted: SME Approvals Granted
Tested-by: Jira Key
Reviewed-by: Xiangpo Zhao <zhaoxp3@motorola.com>
Submit-Approved: Jira Key
In P, run_cmd(poweroff_cmd) can work to trigger /sbin/poweroff. Now in
R, it can not work but still return success. We need to use
kernel_power_off() to trigger power off for factory kill.
The change is referring to (CR).
Change-Id: Ia18faee3138259c7ee35946313e9b0dac75dd244
Signed-off-by: xieqiong2 <xieqiong2@lenovo.com>
Reviewed-on: https://gerrit.mot.com/1763914
SLTApproved: Slta Waiver
SME-Granted: SME Approvals Granted
Tested-by: Jira Key
Reviewed-by: Xiangpo Zhao <zhaoxp3@motorola.com>
Submit-Approved: Jira Key
cherry-pick from:
(CR): arm64/defconfig: disable debug fs on user build
according to android R,
disable debug fs for user build
Change-Id: I985888644c92e14205f7260c423bb88bad026dd9
Signed-off-by: zhaoxp3 <zhaoxp3@motorola.com>
Reviewed-on: https://gerrit.mot.com/1752415
SLTApproved: Slta Waiver
SME-Granted: SME Approvals Granted
Tested-by: Jira Key
Reviewed-by: Wang Wang <wangwang1@lenovo.com>
Submit-Approved: Jira Key
Reviewed-on: https://gerrit.mot.com/1753930
Reviewed-by: Jianguo Liu <liujg6@motorola.com>
For kernel requirements at matrix level 5, Missing config CONFIG_DEBUG_LIST
Add CONFIG_DEBUG_LIST into moto-bengal.config on R
Change-Id: Ia2f1ad1f6425d2b08e14000a7bf69b85e6bdfae6
Reviewed-on: https://gerrit.mot.com/1745633
SME-Granted: SME Approvals Granted
SLTApproved: Slta Waiver
Tested-by: Jira Key
Reviewed-by: Wang Wang <wangwang1@lenovo.com>
Submit-Approved: Jira Key
Propogate changes from (CR).
Dogfooder reported call has no sound issue, it happens on the first
bootup after BOTA upgrading. According to kernel log, filesystem
mount more than 5 minutes, causes locator service timed out.
After discussing with Qcom, they suggest to enlarge this timeout value.
Propagted: https://gerrit.mot.com/#/c/1538288/
Change-Id: I2457b452d21c7396d6a314ae5307c225c52d83da
Signed-off-by: zhouwl <zhouwl@lenovo.com>
Reviewed-on: https://gerrit.mot.com/1740479
SLTApproved: Slta Waiver
SME-Granted: SME Approvals Granted
Tested-by: Jira Key
Reviewed-by: Hujun Liao <liaohj@motorola.com>
Submit-Approved: Jira Key
(cherry picked from commit 9f2105e6420cf9871b3c4b494f70dc98a8449379)
Reviewed-on: https://gerrit.mot.com/1744516
Reviewed-by: Yunfei Guo <guoyf2@motorola.com>
Reviewed-by: Wang Wang <wangwang1@lenovo.com>
This reverts commit f90529f1dec9bdf47082ed0c4d279918459b1be0.
This gerrit was temporarily reverted so as to align all the other
dependent gerrits to merge together.
Mot-CRs-Fixed:(CR)
Change-Id: Idcb99939488d6d83aee1a9c9af4e613820a3a181
Signed-off-by: V(CR) Garodia <vgarodia@codeaurora.org>
Reviewed-on: https://gerrit.mot.com/1730952
SLTApproved: Slta Waiver
SME-Granted: SME Approvals Granted
Tested-by: Jira Key
Reviewed-by: Zilong Zhang <zhangzl7@lenovo.com>
Reviewed-by: Ji Zhao <zhaoji1@lenovo.com>
Reviewed-by: Zhuoran Xu <xuzr3@motorola.com>
Reviewed-by: Zhichao Chen <chenzc2@motorola.com>
Reviewed-by: Tao Sun <suntao2@motorola.com>
Submit-Approved: Jira Key
QCOM KBA-191111223725
[Platform]:
SM6150, SM7150, SM7250, Any platforms use PMI632
[Issue Description]:
If ever use a mismatched temporary profile before receive the matched profile, it may lead to
unexpected inaccurate/nonlinear soc issue, even though you have replaced the correct one, issue
still remains.
[Solution]:
The reason of this issue is because of the saving of incorrect battery info in SDAM, Qcom battery
gauge save the calculated battery info(l(CR) ESR, Capacity...) into the SDAM of PMIC, when reload
a new battery profile, these info will not be cleared, in other words, device will use the incorrect
data to calculate the Soc even though you have loaded a correct matched profile.
To solve this issue, there're two options, one is to re-plug the battery, so that SDAM data will be
cleared. The other option is to merge below workaround, and add device tree property "qcom,
oem-batt-profile-ver" to identify profile change, then driver code will do SDAM clear.
Change-Id: I9fa176cb75da6f9b584553888afa66453576db4e
Signed-off-by: xieqiong2 <xieqiong2@lenovo.com>
Reviewed-on: https://gerrit.mot.com/1732309
SME-Granted: SME Approvals Granted
SLTApproved: Slta Waiver
Tested-by: Jira Key
Reviewed-by: Wei Xu <xuwei9@lenovo.com>
Reviewed-by: Xiangpo Zhao <zhaoxp3@motorola.com>
Submit-Approved: Jira Key
3G ram device has bigger memory pressure than 4G ram device, hence it
has more misreport bugs if we enabled DEBUG_PANIC_ON_OOM. Though we
disable this on 3G ram device, we still can catch oom once device has
no killable process.
Change-Id: Ie12e7c96bac3049031e1e73ce22207df5ae2a8b1
Signed-off-by: huangzq2 <huangzq2@motorola.com>
Reviewed-on: https://gerrit.mot.com/1732467
SME-Granted: SME Approvals Granted
SLTApproved: Slta Waiver
Tested-by: Jira Key
Reviewed-by: Xiangpo Zhao <zhaoxp3@motorola.com>
Submit-Approved: Jira Key
There is a risk if mmi->pres_temp_zone value >= num_temp_zones.
This will casue pointer point to a illegal memory address.
Change-Id: Ic7c3d62c5c59bd41d9fd4f77cd537782c734a486
Reviewed-on: https://gerrit.mot.com/1725712
SME-Granted: SME Approvals Granted
SLTApproved: Slta Waiver
Tested-by: Jira Key
Reviewed-by: Wei Xu <xuwei9@lenovo.com>
Reviewed-by: Huosheng Liao <liaohs@motorola.com>
Submit-Approved: Jira Key
some non-standard QC2.0 charger (e.g. Tronsmart) will rise
vbus to 12V when phone do HVDCP3 detect protocol.
So when vbus reach 12V, we disable HVDCP to workaround it.
refer to (CR)
Change-Id: I1a1fbf1715ac6fbd12a9cd550207b210f16a951d
Signed-off-by: chailu1 <chailu1@lenovo.com>
Reviewed-on: https://gerrit.mot.com/1709435
SME-Granted: SME Approvals Granted
SLTApproved: Slta Waiver
Tested-by: Jira Key
Reviewed-by: Haijian Ma <mahj8@motorola.com>
Reviewed-by: Huosheng Liao <liaohs@motorola.com>
Submit-Approved: Jira Key
When CPU idle is enabled, the idle call should also notifiy the
idle_notifier_call_chain of the change in status. Otherwise some
processes will think the CPU is always active.
Then it will cause some tasks occupy more cpu
Change-Id: Ie11770330bee93ce0e4622a3127ca4850abfb4ba
Signed-off-by: zhaoxp3 <zhaoxp3@motorola.com>
Reviewed-on: https://gerrit.mot.com/1688959
SLTApproved: Slta Waiver
SME-Granted: SME Approvals Granted
Tested-by: Jira Key
Reviewed-by: Wang Wang <wangwang1@lenovo.com>
Submit-Approved: Jira Key
fix compile erro on r due to qcom api changes
Change-Id: I0730df353be93f6f1f06193ddad651b18c399cc1
add R kernel compatibility requirement configs
Change-Id: If67721ab5abd57ad78160d59364e4ed9dd708fbc
config guam R
Change-Id: I1ecb8583728776be53a580c3251a2456713a3723
temp export kallsyms_lookup_name for fail loading some moto kos
Change-Id: I0f22aabb249219a587e696db3d1853a5dcd01afc
when unit suspend, pm_runtime_disalbe() would be called. And
then dev.power.disable_depth number will +1. And its value
will be -1 when pm_runtime_enable() is called.
And if spi bus want to work as soon as system resume, it will call
pm_runtime_get_sync(), which would check the value of
disable_depth. If its value is not 0, spi operation will fail.
The sequence is as following:
runtime_suspend
pm_runtime_disable()-> disable_depth +1
rumtime_resume
pm_runtime_eanble() -> disable_depth -1
spi_sync()
pm_runtime_get_sync -> check the value of disable_depth
But for sometimes, spi operation will earlier than pm_runtime_enable()
called. Then spi_sync() will fail duel to non-zero disable_depth value.
So we add a checking logic before pm_runtime_get_sync() to make sure
disable_depth is 0.
(pick from https://gerrit.mot.com/#/c/1500296/)
Change-Id: I69a0ee3d728ffe3c13d95208f203bd9ed22249b2
Signed-off-by: wengjun1 <wengjun1@motorola.com>
Reviewed-on: https://gerrit.mot.com/1654438
SLTApproved: Slta Waiver
SME-Granted: SME Approvals Granted
Tested-by: Jira Key
Reviewed-by: Huosheng Liao <liaohs@motorola.com>
Submit-Approved: Jira Key
Port the spi changes from bq-6125.
- Do not force suspend for all spi bus.
This will not cause power issue, and can fix clock is closed when SPI
sync message.
- SPI driver missed to check spi runtime status in device suspend.
This may cause spi clocks not closed before device enter deep sleep
So check this status in spi suspend function, if bus not suspened,
break device suspend.
(pick from https://gerrit.mot.com/#/c/1498807/)
Change-Id: Id31492702506361a4ae5e2ccb9c5d381d321e143
Signed-off-by: wengjun1 <wengjun1@motorola.com>
Reviewed-on: https://gerrit.mot.com/1654409
SME-Granted: SME Approvals Granted
SLTApproved: Slta Waiver
Tested-by: Jira Key
Reviewed-by: Huosheng Liao <liaohs@motorola.com>
Submit-Approved: Jira Key
For inbox 10w and typeC product, the DCP current is
2A but not 1.8A. 1.8A come from micro usb product.
Change-Id: Ieb88d33dd8ba9b2fb58de07848ec1293dbc7cdd8
Signed-off-by: chailu1 <chailu1@lenovo.com>
Reviewed-on: https://gerrit.mot.com/1615575
SME-Granted: SME Approvals Granted
SLTApproved: Slta Waiver
Tested-by: Jira Key
Reviewed-by: Huosheng Liao <liaohs@motorola.com>
Submit-Approved: Jira Key
Limit Type-C HIGH charger to MEDIUM at hvdcp disalbed project
in case turbo charging at type-c high charger.
Change-Id: Ie63a88cd46917b0abefb552a000f80ef4bed3b2f
Signed-off-by: xuwei9 <xuwei9@lenovo.com>
Reviewed-on: https://gerrit.mot.com/1611492
SLTApproved: Slta Waiver
SME-Granted: SME Approvals Granted
Tested-by: Jira Key
Reviewed-by: Xiangpo Zhao <zhaoxp3@motorola.com>
Submit-Approved: Jira Key
Pedro Bertoleti