Currently, the get_current_groups API accesses group info, which
increases the usage refcount. If the IOCTL using the
get_current_groups API is called many times, the usage counter
overflows. To avoid this, access group info without taking a
reference. A reference is not required as group info is not
released during the IOCTL call.
Signed-off-by: ANANDU KRISHNAN E <quic_anane@quicinc.com>
Mot-CRs-fixed: (CR)
CVE- fixed: CVE-2024-38402
CRs Fixed: QC-CR#3890158
Signed-off-by: Sipra Patel <siprap@motorola.com>
Change-Id: I266f4dde0ff732f944589ecadc4b72d82a8024e2
Reviewed-on: https://gerrit.mot.com/3091032
SME-Granted: SME Approvals Granted
SLTApproved: Slta Waiver
Tested-by: Jira Key
Reviewed-by: Varun Shrivastava <varunshrivastava@motorola.com>
Reviewed-by: Xiangpo Zhao <zhaoxp3@motorola.com>
Submit-Approved: Jira Key
Currently, the DSP updates header buffers with unused DMA handle fds.
In the put_args section, if any DMA handle FDs are present in the
header buffer, the corresponding map is freed. However, since the
header buffer is exposed to users in unsigned PD, users can update
invalid FDs. If this invalid FD matches with any FD that is already
in use, it could lead to a use-after-free (UAF) vulnerability.
As a solution,add DMA handle references for DMA FDs, and the map for
the FD will be freed only when a reference is found.
Acked-by: quic_anane <quic_anane@quicinc.com>
Change-Id: I83ae12329003db14dae8d430ab74925f2a30947b
Signed-off-by: Ansa Ahmed <quic_ansa@quicinc.com>
---
Mot-CRs-fixed: (CR)
CVE- fixed: CVE-2024-21455
CRs Fixed: QC-CR#3875202
Signed-off-by: Sipra Patel <siprap@motorola.com>
Reviewed-on: https://gerrit.mot.com/3075244
SME-Granted: SME Approvals Granted
SLTApproved: Slta Waiver
Tested-by: Jira Key
Reviewed-by: Varun Shrivastava <varunshrivastava@motorola.com>
Reviewed-by: Xiangpo Zhao <zhaoxp3@motorola.com>
Submit-Approved: Jira Key
Currently, remote heap maps get added to the global list before the
fastrpc_internal_mmap function completes the mapping. Meanwhile, the
fastrpc_internal_munmap function accesses the map, starts unmapping, and
frees the map before the fastrpc_internal_mmap function completes,
resulting in a use-after-free (UAF) issue. Add the map to the list after
the fastrpc_internal_mmap function completes the mapping.
Mot-CRs-fixed: (CR)
CVE-Fixed: CVE-2024-33060
CRs-Fixed: 3735984
Bug: 350500584
Change-Id: Ia524f142edba57a1f389dd0e5c83a1967c7f5a59
Acked-by: Abhishek Singh <abhishes@qti.qualcomm.com>
Signed-off-by: Santosh Sakore <quic_ssakore@quicinc.com>
(cherry picked from commit 6f9f631c90)
Signed-off-by: Ashutosh Verma <ashverma@motorola.com>
Reviewed-on: https://gerrit.mot.com/3032196
SME-Granted: SME Approvals Granted
SLTApproved: Slta Waiver
Tested-by: Jira Key
Reviewed-by: Varun Shrivastava <varunshrivastava@motorola.com>
Reviewed-by: Xiangpo Zhao <zhaoxp3@motorola.com>
Submit-Approved: Jira Key
The functions qcom_slim_ngd_xfer_msg and
qcom_slim_ngd_xfer_msg_sync declare a local completion
variable called done. However, this variable is accessed
beyond the scope of these functions.
To address this issue:
1. Instead of keeping done as a local variable,
move it to qcom_slim_ngd_ctrl.
2. Initialize done during the probe phase.
3. Use this variable for handling transfer and
synchronization messages.
Mot-CRs-fixed: (CR)
CVE-Fixed: CVE-2024-33045
CRs-Fixed: 3745620
Change-Id: If97b71e2db730ab21bfd07479d2737b0546e1f8e
Signed-off-by: Mehul Raninga <quic_mraninga@quicinc.com>
Signed-off-by: Ashutosh Verma <ashverma@motorola.com>
Reviewed-on: https://gerrit.mot.com/2991299
SLTApproved: Slta Waiver
SME-Granted: SME Approvals Granted
Tested-by: Jira Key
Reviewed-by: Chakradhar Gajjala <gajjalac@motorola.com>
Reviewed-by: Xiangpo Zhao <zhaoxp3@motorola.com>
Submit-Approved: Jira Key
[ Upstream commit 47d8ac011fe1c9251070e1bd64cb10b48193ec51 ]
Garbage collector does not take into account the risk of embryo getting
enqueued during the garbage collection. If such embryo has a peer that
carries SCM_RIGHTS, two consecutive passes of scan_children() may see a
different set of children. Leading to an incorrectly elevated inflight
count, and then a dangling pointer within the gc_inflight_list.
sockets are AF_UNIX/SOCK_STREAM
S is an unconnected socket
L is a listening in-flight socket bound to addr, not in fdtable
V's fd will be passed via sendmsg(), gets inflight count bumped
connect(S, addr) sendmsg(S, [V]); close(V) __unix_gc()
---------------- ------------------------- -----------
NS = unix_create1()
skb1 = sock_wmalloc(NS)
L = unix_find_other(addr)
unix_state_lock(L)
unix_peer(S) = NS
// V count=1 inflight=0
NS = unix_peer(S)
skb2 = sock_alloc()
skb_queue_tail(NS, skb2[V])
// V became in-flight
// V count=2 inflight=1
close(V)
// V count=1 inflight=1
// GC candidate condition met
for u in gc_inflight_list:
if (total_refs == inflight_refs)
add u to gc_candidates
// gc_candidates={L, V}
for u in gc_candidates:
scan_children(u, dec_inflight)
// embryo (skb1) was not
// reachable from L yet, so V's
// inflight remains unchanged
__skb_queue_tail(L, skb1)
unix_state_unlock(L)
for u in gc_candidates:
if (u.inflight)
scan_children(u, inc_inflight_move_tail)
// V count=1 inflight=2 (!)
If there is a GC-candidate listening socket, lock/unlock its state. This
makes GC wait until the end of any ongoing connect() to that socket. After
flipping the lock, a possibly SCM-laden embryo is already enqueued. And if
there is another embryo coming, it can not possibly carry SCM_RIGHTS. At
this point, unix_inflight() can not happen because unix_gc_lock is already
taken. Inflight graph remains unaffected.
Mot-CRs-fixed: (CR)
CVE-Fixed: CVE-2024-26923
Bug: 336268889
Fixes: 1fd05ba5a2 ("[AF_UNIX]: Rewrite garbage collector, fixes race.")
Signed-off-by: Michal Luczaj <mhal@rbox.co>
Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Link: https://lore.kernel.org/r/20240409201047.1032217-1-mhal@rbox.co
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Change-Id: I26e0e5ef98139d739bccd6a33aa518376590a5d1
Signed-off-by: Gajjala Chakradhar <gajjalac@motorola.com>
Reviewed-on: https://gerrit.mot.com/2992981
SME-Granted: SME Approvals Granted
SLTApproved: Slta Waiver
Tested-by: Jira Key
Reviewed-by: Xiangpo Zhao <zhaoxp3@motorola.com>
Submit-Approved: Jira Key
(cherry picked from commit 8be8171b515b73fa028df2188d5f0a0ff1ff71ff)
Commit 6d98eb95b450 ("binder: avoid potential data leakage when copying
txn") introduced changes to how binder objects are copied. In doing so,
it unintentionally removed an offset alignment check done through calls
to binder_alloc_copy_from_buffer() -> check_buffer().
These calls were replaced in binder_get_object() with copy_from_user(),
so now an explicit offset alignment check is needed here. This avoids
later complications when unwinding the objects gets harder.
It is worth noting this check existed prior to commit 7a67a39320
("binder: add function to copy binder object from buffer"), l(CR)
removed due to redundancy at the time.
Fixes: 6d98eb95b450 ("binder: avoid potential data leakage when copying txn")
Cc: <stable@vger.kernel.org>
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Mot-CRs-fixed: (CR)
CVE-Fixed: CVE-2024-26926
Bug: 320661088
Link: https://lore.kernel.org/all/20240330190115.1877819-1-cmllamas@google.com/
Change-Id: Iaddabaa28de7ba7b7d35dbb639d38ca79dbc5077
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: Ashutosh Verma <ashverma@motorola.com>
Reviewed-on: https://gerrit.mot.com/2960965
SME-Granted: SME Approvals Granted
SLTApproved: Slta Waiver
Tested-by: Jira Key
Reviewed-by: Chakradhar Gajjala <gajjalac@motorola.com>
Reviewed-by: Xiangpo Zhao <zhaoxp3@motorola.com>
Submit-Approved: Jira Key
In commit 92f1655aa2b2 ("net: fix __dst_negative_advice() race") the
struct dst_ops callback negative_advice is callback changes function
parameters. But as this pointer is part of a structure that is tracked
in the ABI checker, the tool triggers when this is changed.
However, the callback pointer is internal to the networking stack, so
changing the function type is safe, so needing to preserve this is not
required. To do so, switch the function pointer type back to the old
one so that the checking tools pass, AND then do a hard cast of the
function pointer to the new type when assigning and calling the
function.
Mot-CRs-fixed: (CR)
Bug: 343727534
Fixes: 92f1655aa2b2 ("net: fix __dst_negative_advice() race")
Change-Id: I48d4ab4bbd29f8edc8fbd7923828b7f78a23e12e
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Reviewed-on: https://gerrit.mot.com/2996719
SME-Granted: SME Approvals Granted
SLTApproved: Slta Waiver
Tested-by: Jira Key
Reviewed-by: Zhihong Kang <kangzh@motorola.com>
Reviewed-by: Huosheng Liao <liaohs@motorola.com>
Submit-Approved: Jira Key
__dst_negative_advice() does not enforce proper RCU rules when
sk->dst_cache must be cleared, leading to possible UAF.
RCU rules are that we must first clear sk->sk_dst_cache,
then call dst_release(old_dst).
Note that sk_dst_reset(sk) is implementing this protocol correctly,
while __dst_negative_advice() uses the wrong order.
Given that ip6_negative_advice() has special logic
against RTF_CACHE, this means each of the three ->negative_advice()
existing methods must perform the sk_dst_reset() themselves.
Note the check against NULL dst is centralized in
__dst_negative_advice(), there is no need to duplicate
it in various callbacks.
Many thanks to Clement Lecigne for tracking this issue.
This old bug became visible after the blamed commit, using UDP sockets.
Mot-CRs-fixed: (CR)
Bug: 343727534
Fixes: a87cb3e48e ("net: Facility to report route quality of connected sockets")
Reported-by: Clement Lecigne <clecigne@google.com>
Diagnosed-by: Clement Lecigne <clecigne@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Tom Herbert <tom@herbertland.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Link: https://lore.kernel.org/r/20240528114353.1794151-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 92f1655aa2b2294d0b49925f3b875a634bd3b59e)
[Lee: Trivial/unrelated conflict - no change to the patch]
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I293734dca1b81fcb712e1de294f51e96a405f7e4
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Reviewed-on: https://gerrit.mot.com/2996680
SME-Granted: SME Approvals Granted
SLTApproved: Slta Waiver
Tested-by: Jira Key
Reviewed-by: Zhihong Kang <kangzh@motorola.com>
Reviewed-by: Huosheng Liao <liaohs@motorola.com>
Submit-Approved: Jira Key
Thread 1 can make a to call fastrpc_mmap_create under internal mem map
and release fl->map_mutex. Thread 2 can make call to internal mem unmap,
acquire fl->map_mutex and get same map though fastrpc_mmap_remove.
Thread 1 fail in fastrpc_mem_map_to_dsp jumps to bail and do map free.
Thread 2 still holds same map which can lead use after free. Serialize
fastrpc internal mem map and unmap.
Mot-CRs-fixed: (CR)
CVE-Fixed: CVE-2023-43514
CRs-Fixed: 3613254
Bug: 303101664
Change-Id: I54a3602914b43fc67635c0de193bd21aa13daaa3
Signed-off-by: DEEPAK SANNAPAREDDY <quic_sdeeredd@quicinc.com>
Signed-off-by: Ashutosh Verma <ashverma@motorola.com>
Reviewed-on: https://gerrit.mot.com/2832044
SLTApproved: Slta Waiver
SME-Granted: SME Approvals Granted
Tested-by: Jira Key
Reviewed-by: Chakradhar Gajjala <gajjalac@motorola.com>
Reviewed-by: Xiangpo Zhao <zhaoxp3@motorola.com>
Submit-Approved: Jira Key
4117cebf1a9f ("psi: Optimize task switch inside shared cgroups")
introduced a race condition that corrupts internal psi state. This
manifests as kernel warnings, sometimes followed by bogusly high IO
pressure:
psi: task underflow! cpu=1 t=2 tasks=[0 0 0 0] clear=c set=0
(schedule() decreasing RUNNING and ONCPU, both of which are 0)
psi: incosistent task state! task=2412744:systemd cpu=17 psi_flags=e clear=3 set=0
(cgroup_move_task() clearing MEMSTALL and IOWAIT, but task is MEMSTALL | RUNNING | ONCPU)
What the offending commit does is batch the two psi callbacks in
schedule() to reduce the number of cgroup tree updates. When prev is
deactivated and removed from the runqueue, nothing is done in psi at
first; when the task switch completes, TSK_RUNNING and TSK_IOWAIT are
updated along with TSK_ONCPU.
However, the deactivation and the task switch inside schedule() aren't
atomic: pick_next_task() may drop the rq lock for load balancing. When
this happens, cgroup_move_task() can run after the task has been
physically dequeued, but the psi updates are still pending. Since it
looks at the task's scheduler state, it doesn't move everything to the
new cgroup that the task switch that follows is about to clear from
it. cgroup_move_task() will leak the TSK_RUNNING count in the old
cgroup, and psi_sched_switch() will underflow it in the new cgroup.
A similar thing can happen for iowait. TSK_IOWAIT is usually set when
a p->in_iowait task is dequeued, but again this update is deferred to
the switch. cgroup_move_task() can see an unqueued p->in_iowait task
and move a non-existent TSK_IOWAIT. This results in the inconsistent
task state warning, as well as a counter underflow that will result in
permanent IO ghost pressure being reported.
Fix this bug by making cgroup_move_task() use task->psi_flags instead
of looking at the potentially mismatching scheduler state.
[ We used the scheduler state historically in order to not rely on
task->psi_flags for anything but debugging. But that ship has sailed
anyway, and this is simpler and more robust.
We previously already batched TSK_ONCPU clearing with the
TSK_RUNNING update inside the deactivation call from schedule(). But
that ordering was safe and didn't result in TSK_ONCPU corruption:
unl(CR) most places in the scheduler, cgroup_move_task() only checked
task_current() and handled TSK_ONCPU if the task was still queued. ]
Fixes: 4117cebf1a9f ("psi: Optimize task switch inside shared cgroups")
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20210503174917.38579-1-hannes@cmpxchg.org
Change-Id: I83fc22d7ecb515896a526892f40066353a6dadd0
Mot-CRs-fixed: (CR)
Reviewed-on: https://gerrit.mot.com/2408024
SME-Granted: SME Approvals Granted
SLTApproved: Slta Waiver
Tested-by: Jira Key
Reviewed-by: Xiangpo Zhao <zhaoxp3@motorola.com>
Submit-Approved: Jira Key
Reviewed-on: https://gerrit.mot.com/2817400
Reviewed-by: Hongshu Lou <louhs1@motorola.com>
Reviewed-by: Huosheng Liao <liaohs@motorola.com>
When using OCP charger in charge only mode,the input current limit is 2A.
But the expected icl is 1A.
In smblib_apsd_results:
[OCP] = {
.name = "OCP",
.bit = OCP_CHARGER_BIT,
.val = POWER_SUPPLY_TYPE_USB_DCP
}
So the OCP charger power supply type is USB_DCP.
And in func update_sw_icl_max,it will using
"vote(chg->usb_icl_votable, SW_ICL_MAX_VOTER, true, rp_ua);"
to set the usb_icl to be 2A.
So we need to recheck the OCP_CHARGER_BIT and reset usb_icl
to OCP_CURRENT_UA (1A).
Change-Id: Ifd4ccceb91c227c12e5f4b628606f2de166155af
Signed-off-by: Guocheng Wang <wanggc6@motorola.com>
Reviewed-on: https://gerrit.mot.com/2775176
SLTApproved: Slta Waiver
SME-Granted: SME Approvals Granted
Tested-by: Jira Key
Reviewed-by: Haijian Ma <mahj8@motorola.com>
Reviewed-by: Huosheng Liao <liaohs@motorola.com>
Submit-Approved: Jira Key
On previous projects, Micron use Samsung driver to fulfill the
TW, HPB and HID features, so could use CONFIG_MICRON_HPB to check
if the Micron chip of one project support TW, HPB and HID.
However, we have use original WB to instead of Samsung TW, and disable
HPB also. Now, Micron use Samsung HID driver only, we need add Micron
HID config to enable Samsung feature init, or Micron HID funcion will
not active.
Change-Id: Ie75bd535e4b56e7d359f3b8687fa30405ade6358
Reviewed-on: https://gerrit.mot.com/2774267
SME-Granted: SME Approvals Granted
SLTApproved: Slta Waiver
Tested-by: Jira Key
Reviewed-by: Zonghua Liu <a17671@motorola.com>
Reviewed-by: Huosheng Liao <liaohs@motorola.com>
Submit-Approved: Jira Key
Mot-CRs-fixed: (CR)
When an outside process lowers one of the memory limits of a cgroup (or
uses the force_empty knob in cgroup1), direct reclaim is performed in the
context of the write(), in order to directly enforce the new limit and
have it being met by the time the write() returns.
Currently, this reclaim activity is accounted as memory pressure in the
cgroup that the writer(!) belongs to. This is unexpected. It
specifically causes problems for senpai
(https://github.com/facebookincubator/senpai), which is an agent that
routinely adjusts the memory limits and performs associated reclaim work
in tens or even hundreds of cgroups running on the host. The cgroup that
senpai is running in itself will report elevated levels of memory
pressure, even though it itself is under no memory shortage or any sort of
distress.
Move the psi annotation from the central cgroup reclaim function to
callsites in the allocation context, and thereby no longer count any
limit-setting reclaim as memory pressure. If the newly set limit causes
the workload inside the cgroup into direct reclaim, that of course will
continue to count as memory pressure.
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Shakeel Butt <shakeelb@google.com>
Reviewed-by: Roman Gushchin <guro@fb.com>
Acked-by: Chris Down <chris@chrisdown.name>
Acked-by: Michal Hocko <mhocko@suse.com>
Link: http://lkml.kernel.org/r/20200728135210.379885-2-hannes@cmpxchg.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Change-Id: I49bbfc4c462e1e42264558566ab495e695d9e00d
Reviewed-on: https://gerrit.mot.com/2771207
SME-Granted: SME Approvals Granted
SLTApproved: Slta Waiver
Tested-by: Jira Key
Reviewed-by: Yonghui Jia <jiayh2@motorola.com>
Reviewed-by: Huosheng Liao <liaohs@motorola.com>
Submit-Approved: Jira Key
Add rpmsg support for slatecom interface driver to
send msm state transition commands to slate.
Add Opcodes to be received on slate-ctrl channel from hal.
Send TWM_ENTER, DEEP SLEEP ENTER & EXIT to slate.
Mot-CRs-fixed: (CR)
CVE-Fixed: CVE-2023-33085
CRs-Fixed: 3512209
Change-Id: Ic29b116da7b90e1a1d71a14b970a2a53b1b3c20f
Signed-off-by: Praveen koya <pkoya@codeaurora.org>
Signed-off-by: Ashutosh Verma <ashverma@motorola.com>
Reviewed-on: https://gerrit.mot.com/2762749
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 possibility that network will be used after free.
This change is to fix this issue.
Mot-CRs-fixed: (CR)
CVE-Fixed: CVE-2023-33114
CRs-Fixed: 3520999
Change-Id: I25eaf33f2a641127f13ec20df5da29d2b2923828
Signed-off-by: Jilai Wang <quic_jilaiw@quicinc.com>
Sigend-off-by: Ashutosh Verma <ashverma@motorola.com>
Reviewed-on: https://gerrit.mot.com/2760383
SME-Granted: SME Approvals Granted
SLTApproved: Slta Waiver
Tested-by: Jira Key
Reviewed-by: Xiangpo Zhao <zhaoxp3@motorola.com>
Submit-Approved: Jira Key
Mot-CRs-fixed: (CR)
process_madvise currently requires ptrace attach capability.
PTRACE_MODE_ATTACH gives one process complete control over another
process. It effectively removes the security boundary between the
two processes (in one direction). Granting ptrace attach capability
even to a system process is considered dangerous since it creates an
attack surface. This severely limits the usage of this API.
The operations process_madvise can perform do not affect the correctness
of the operation of the target process; they only affect where the data
is physically located (and therefore, how fast it can be accessed).
What we want is the ability for one process to influence another process
in order to optimize performance across the entire system while leaving
the security boundary intact.
Replace PTRACE_MODE_ATTACH with a combination of PTRACE_MODE_READ
and CAP_SYS_NICE. PTRACE_MODE_READ to prevent leaking ASLR metadata
and CAP_SYS_NICE for influencing process performance.
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Acked-by: David Rientjes <rientjes@google.com>
Link: https://lore.kernel.org/lkml/202101111033.2D03EA97@keescook/T/#u
Test: built and flashed kernel
Bug: 153444106
Signed-off-by: Edgar Arriaga <edgararriaga@google.com>
Change-Id: I3624a8b0697d70f23587c1dcb746ba753c301f45
Reviewed-on: https://gerrit.mot.com/2765787
SME-Granted: SME Approvals Granted
SLTApproved: Slta Waiver
Tested-by: Jira Key
Reviewed-by: Zhangqing Huang <huangzq2@motorola.com>
Reviewed-by: Huosheng Liao <liaohs@motorola.com>
Submit-Approved: Jira Key
Mot-CRs-fixed: (CR)
it only has 5 parameters in libc, currently has 6 parameters in kernel to
cause it return -EINVAL in "flags" check
libc defined:
ssize_t process_madvise(int __pid_fd, const struct iovec* __iov, size_t __count, int __advice, unsigned __flags) __INTRODUCED_IN(31);
This reverts commit 306d0c3e29.
Change-Id: If69151ae97498f4db210fbe4d16bf53ad4abf42b
Reviewed-on: https://gerrit.mot.com/2765786
SME-Granted: SME Approvals Granted
SLTApproved: Slta Waiver
Tested-by: Jira Key
Reviewed-by: Zhangqing Huang <huangzq2@motorola.com>
Reviewed-by: Huosheng Liao <liaohs@motorola.com>
Submit-Approved: Jira Key
WHAT: Disable the kernel configs related to debug gpio, clock and regulator
dumping its values for miami
WHY: This is halting penang driver sgm4154x_chg_mmi, because this config will
eventually make sgm4154x_chg_mmi call msleep inside an atomic operation
(read the registers that CONFIG_DUMP_* is requiring) and since penang
has CONFIG_PANIC_ON_SCHED_BUG it will call BUG(), which will panic
Change-Id: I8768dd99eafc854c0cd55cd57b51b241798ea64f
Reviewed-on: https://gerrit.mot.com/2759524
SME-Granted: SME Approvals Granted
SLTApproved: Slta Waiver
Reviewed-by: Rafael Ortolan <rafones@motorola.com>
Tested-by: Jira Key
Reviewed-by: Gilberto Gambugge Neto <gambugge@motorola.com>
Submit-Approved: Jira Key
The prerequisite for AICL is that VBUS is required,
so when usb or charger cable is not connected
(neither usbin nor dcin exists),
we need to skip re-run AICL.
Change-Id: I2d039fbfaa090ac3e7682e4ddb9889a278503484
Signed-off-by: Guocheng Wang <wanggc6@motorola.com>
Reviewed-on: https://gerrit.mot.com/2760500
SME-Granted: SME Approvals Granted
SLTApproved: Slta Waiver
Tested-by: Jira Key
Reviewed-by: Wei Wei <weiweij@motorola.com>
Reviewed-by: Huosheng Liao <liaohs@motorola.com>
Submit-Approved: Jira Key
Using Type-C to 3.5mm Headphone 2-in-1 Adapter，COM charging Failed.
Because the devices are in off-mode when usb plug-in,bootup process might
cause some detection delay.
So when DUT power on with typec and the typec vbus is exist,we need to
wait some times for check type-c is connected before call
smb5_typec_attach_detach_irq_handler.
Change-Id: I8ea0e904bc493c13d666a09f81c34d33fdb2663f
Signed-off-by: Guocheng Wang <wanggc6@motorola.com>
Reviewed-on: https://gerrit.mot.com/2752957
SLTApproved: Slta Waiver
SME-Granted: SME Approvals Granted
Tested-by: Jira Key
Reviewed-by: Haijian Ma <mahj8@motorola.com>
Reviewed-by: Huosheng Liao <liaohs@motorola.com>
Submit-Approved: Jira Key
Only add OEM DATA on QGKI and keep the origin struct on GKI
to avoid break KMI.
Change-Id: I6678db4ce211a21c91c5305024cb18b9f5e1265e
Reviewed-on: https://gerrit.mot.com/2749363
SLTApproved: Slta Waiver
SME-Granted: SME Approvals Granted
Tested-by: Jira Key
Reviewed-by: Xiangpo Zhao <zhaoxp3@motorola.com>
Submit-Approved: Jira Key
GPIOLIB_IS_REQUEST() checking only return true when the gpio using request_gpio functions.
So if using pinctrl and subsystem gpio configuration, this checking logic will block.
And we will get lots of following errors:
[ 453.757397] gpio25: is not allocated in gpiolib
After removing this logic, we could get the gpio status:
09-07 21:27:55.968 0 0 W gpio25 : in low func0 2mA pull down
Change-Id: I2d03e86e3a236bd81a72dfa20cb9e0be41354348
Reviewed-on: https://gerrit.mot.com/2733812
SME-Granted: SME Approvals Granted
SLTApproved: Slta Waiver
Tested-by: Jira Key
Reviewed-by: Wei Wei <weiweij@motorola.com>
Reviewed-by: Huosheng Liao <liaohs@motorola.com>
Submit-Approved: Jira Key
Open this func for fogos in kernel.
Change-Id: If8458d06fa7358453e43ce48da4f90762ce10a22
Signed-off-by: Liu Yang <liuyang81@lenovo.com>
Reviewed-on: https://gerrit.mot.com/2727777
SME-Granted: SME Approvals Granted
SLTApproved: Slta Waiver
Tested-by: Jira Key
Reviewed-by: Bolei Shang <shangbl1@lenovo.com>
Reviewed-by: Ji Zhao <zhaoji1@lenovo.com>
Reviewed-by: <zhanys2@motorola.com>
Reviewed-by: <mingjw1@motorola.com>
Reviewed-by: Simon C <chenzm8@motorola.com>
Reviewed-by: Zhang Lei <zhangl82@motorola.com>
Reviewed-by: <wuhao38@lenovo.com>
Reviewed-by: Guobin Zhang <zhanggb@motorola.com>
Submit-Approved: Jira Key
WHAT: Disable the kernel configs related to debug gpio, clock and regulator
dumping its values for penang
WHY: This is halting penang driver sgm4154x_chg_mmi, because this config will
eventually make sgm4154x_chg_mmi call msleep inside an atomic operation
(read the registers that CONFIG_DUMP_* is requiring) and since penang
has CONFIG_PANIC_ON_SCHED_BUG it will call BUG(), which will panic
Change-Id: I26eb620e832dbf9e94acd4cb22cd87eee444f350
Reviewed-on: https://gerrit.mot.com/2719824
SME-Granted: SME Approvals Granted
SLTApproved: Slta Waiver
Tested-by: Jira Key
Reviewed-by: Gilberto Gambugge Neto <gambugge@motorola.com>
Submit-Approved: Jira Key
Reviewed-by: Rafael Ortolan <rafones@motorola.com>
The error is from https://gerrit.mot.com/#/c/2710381/
Function gpio_debug_print_enabled is implemented under
the control of DEBUG_FS.
But user version do not have this macro definition.
Error message is as following:
ld.lld: error: undefined symbol: gpio_debug_print_enabled
>>> referenced by lpm-levels.c:1124 (/home/weiweij/work/u/fogoNA/main/kernel/msm-5.4/drivers/cpuidle/lpm-levels.c:1124)
>>> vmlinux.o:(cluster_configure)
make[1]: *** [/home/weiweij/work/u/fogoNA/main/kernel/msm-5.4/Makefile:1197: vmlinux] Error 1
Change-Id: I57ae5a19f43dd4bf59196c8d18919f15acf03d4b
Reviewed-on: https://gerrit.mot.com/2712951
SME-Granted: SME Approvals Granted
SLTApproved: Slta Waiver
Tested-by: Jira Key
Reviewed-by: Wei Wei <weiweij@motorola.com>
Reviewed-by: Huosheng Liao <liaohs@motorola.com>
Submit-Approved: Jira Key
add "device_remove_bin_file" white list for aw8838 driver.
it could be found in the latest abi_gki_aarch64*.xml file.
Change-Id: I1d73efccfd0d6f2e5d412a3e327843b04b62ce2b
Signed-off-by: liaohj <liaohj@lenovo.com>
Reviewed-on: https://gerrit.mot.com/2706089
SLTApproved: Slta Waiver
SME-Granted: SME Approvals Granted
Tested-by: Jira Key
Reviewed-by: Zhenxin Xi <xizx@motorola.com>
Submit-Approved: Jira Key
we are not serving system suspend if spi xfers were in progress, doing
force suspend if spi xfers were completed.
Port of patch spi_geni_fix2.patch provided by qcom in case 06677540
Change-Id: I929031556694abf77e78e573a6f56986dc8667e9
Reviewed-on: https://gerrit.mot.com/2697260
SME-Granted: SME Approvals Granted
SLTApproved: Slta Waiver
Tested-by: Jira Key
Reviewed-by: Bruno Oliveira <brunosoe@motorola.com>
Reviewed-by: Rafael Ortolan <rafones@motorola.com>
Reviewed-by: Jun Weng <wengjun1@motorola.com>
Reviewed-by: Huosheng Liao <liaohs@motorola.com>
Submit-Approved: Jira Key
fix the error dtb project config
the error will block start-up, the error uart log is as below:
Best Soc Dtb 0x1FB/0x10000/0x0/0x0
Unable to find the Board Dtb
Error: Board Dtbo blob not found
BootLinux() failed: Not Found
Slot _a is not looking good
Change-Id: Id147a84a0beafba097b2915303d9944834e9c550
Signed-off-by: Franz Wang <wangxf14@motorola.com>
Reviewed-on: https://gerrit.mot.com/2684376
Reviewed-by: Xiaojun Ji <jixj@motorola.com>
SLTApproved: Slta Waiver
SME-Granted: SME Approvals Granted
Tested-by: Jira Key
Reviewed-by: Huosheng Liao <liaohs@motorola.com>
Submit-Approved: Jira Key
