There is a possibility of client driver's dev_wake request
as part mhi_device_get() racing with M1 state transition
event processing. This can result in a scenario where client
finds MHI state as M0 after mhi_device_get() returns only to
be changed later as M1 event processing is still pending on
different CPU core.
It causes M0 -> M2 -> M0 state transition after mhi_device_get()
has already returned. This isn't expected by client and currently
treats that as fatal error. Also, as per MHI spec host must allow
M1 -> M2 transition for device and it shouldn't abort that.
However, clients can ignore that transition as device is expected
to immediately move from M2 to M0 without entering deep sleep
state. Hence, it must be safe to access their MMIO.
To simplify this logic, introduce mhi_device_get_sync_atomic()
function that can be used by clients to achieve the same and once
it returns success they don't need to have any explicit MHI state
checks.
Change-Id: I0b4a1ad723a0444ee2402bf171fc5ffc46afcdce
Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
Add check to restrict index underflow.This is to avoid
that it does not access invalid index.
Change-Id: Ib971033c5820ca4dab38ace3b106c7b1b42529e4
Acked-by: Gururaj Chalger <gchalger@qti.qualcomm.com>
Signed-off-by: Mohammed Nayeem Ur Rahman <mohara@codeaurora.org>
Dump PA_VS_STATUS_REG1 when full reset is needed in eh, which is helpful
for error debugging.
Change-Id: Iad3c2fc09c88598428762b5da09e13b46493fc7d
Signed-off-by: Can Guo <cang@codeaurora.org>
Enable UAPI_HEADER_TEST in the Lahaina GKI defconfig for UAPI sanity
checks.
Change-Id: Ic0dedbad7cd0782018c8e6f32d4337c6e211a809
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
When unmapping memory in S1, treat zero-sized sg-lists as invalid
inputs.
Change-Id: I477cd0808eea1200873c50470c8b73d9162428e4
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
This change removes not informative prints.
Change-Id: Ic4c4e6fef752c72082b260b2e34873bd994bc62d
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Correct condition for SW USB mode when setup sysfs buf to fix the issue
that the allocated buffer size is always 32M for memory mode with sw_usb
is enabled.
Change-Id: Id545ecfa21378f49ddeac4c3c3f4fe51f744e69b
Signed-off-by: Mao Jinlong <jinlmao@codeaurora.org>
The current code sets per-cpu variable sd_asym_cpucapacity while
building sched domains even when there are no asymmetric CPUs.
This is done to make sure that EAS remains enabled on a b.L system
after hotplugging out all big/LITTLE CPUs. However it is causing
the below warning during CPU hotplug.
[13988.932604] pc : static_key_slow_dec_cpuslocked+0xe8/0x150
[13988.932608] lr : static_key_slow_dec_cpuslocked+0xe8/0x150
[13988.932610] sp : ffffffc010333c00
[13988.932612] x29: ffffffc010333c00 x28: ffffff8138d88088
[13988.932615] x27: 0000000000000000 x26: 0000000000000081
[13988.932618] x25: ffffff80917efc80 x24: ffffffc010333c60
[13988.932621] x23: ffffffd32bf09c58 x22: 0000000000000000
[13988.932623] x21: 0000000000000000 x20: ffffff80917efc80
[13988.932626] x19: ffffffd32bf0a3e0 x18: ffffff8138039c38
[13988.932628] x17: ffffffd32bf2b000 x16: 0000000000000050
[13988.932631] x15: 0000000000000050 x14: 0000000000040000
[13988.932633] x13: 0000000000000178 x12: 0000000000000001
[13988.932636] x11: 16a9ca5426841300 x10: 16a9ca5426841300
[13988.932639] x9 : 16a9ca5426841300 x8 : 16a9ca5426841300
[13988.932641] x7 : 0000000000000000 x6 : ffffff813f4edadb
[13988.932643] x5 : 0000000000000000 x4 : 0000000000000004
[13988.932646] x3 : ffffffc010333880 x2 : ffffffd32a683a2c
[13988.932648] x1 : ffffffd329355498 x0 : 000000000000001b
[13988.932651] Call trace:
[13988.932656] static_key_slow_dec_cpuslocked+0xe8/0x150
[13988.932660] partition_sched_domains_locked+0x1f8/0x80c
[13988.932666] sched_cpu_deactivate+0x9c/0x13c
[13988.932670] cpuhp_invoke_callback+0x6ac/0xa8c
[13988.932675] cpuhp_thread_fun+0x158/0x1ac
[13988.932678] smpboot_thread_fn+0x244/0x3e4
[13988.932681] kthread+0x168/0x178
[13988.932685] ret_from_fork+0x10/0x18
The mismatch between increment/decrement of sched_asym_cpucapacity
static key is resulting in the above warning. It is due to
the fact that the increment happens only when the system really
has asymmetric capacity CPUs. This check is done by going through
each CPU capacity. So when system becomes SMP during hotplug,
the increment never happens. However the decrement of this static
key is done when any of the currently online CPU has per-cpu variable
sd_asym_cpucapacity value as non-NULL. Since we always set this
variable, we run into this issue.
Our goal was to enable EAS on SMP. To achieve that enable EAS and
build perf domains (required for compute energy) irrespective
of per-cpu variable sd_asym_cpucapacity value. In this way we
no longer have to enable sched_asym_cpucapacity feature on SMP
to enable EAS.
Change-Id: Id46f2b80350b742c75195ad6939b814d4695eb07
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
We have made the new idle CPU selection for load balance energy
aware. For example, if a silver CPU does not have any misfit
tasks but is overloaded, we have to select a silver CPU not
gold CPU. However, this extra checks are needed only when the
system has asymmetric capacity CPUs. So we should depend on
sched_asym_cpucapacity feature instead of sched_energy_present.
Later patches enable sched_energy_present for SMP systems also.
Change-Id: Ie4fae9d1c17511f15b48b92dd61395d1689e1612
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
By default CONFIG_* user-space leak checker marks it as warning but
we should mark them as error so that we can catch such usage at the
compile time itself.
Change-Id: I5f14f7f881e46843f2e0cc0957fc0b730e76aa93
Signed-off-by: Trilok Soni <tsoni@codeaurora.org>
Add sysstats.h taskstats.h into the temporary bypass list. It should be removed
later once the CONFIG_* checks gets merged.
CRs-Fixed: 2664401
Change-Id: Icfedb19b22dcf59d4ae0e8d7bd9fddfc762d9731
Signed-off-by: Trilok Soni <tsoni@codeaurora.org>
Fix adapt sequence for G4 and don't dump registers
on Line-reset.
Change-Id: Ibbe09d75c1655d2400878305e7b38e7e2f744e52
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
For voice usecases, while opening the slimbus
slave ports, currently data format LPCM(1) is used.
SB master uses data format as unspecified(0). SB master's
data format overwrites the slave side configuration.
In the rare cases, this mismatch may lead to pop sound
in SCO Tx(BT FW->LPASS) at the very beginning when
voice is switched from speaker/handset to BT from call UI.
To fix this, use the data format as unspecified during
opening of the slimbus slave ports for voice cases.
CRs-Fixed: 2710472
Change-Id: Ia9b1d23cbf04d1b8056d7b7f7c84a066437e1682
Signed-off-by: Satish Kodishala <skodisha@codeaurora.org>
__bpf_skb_max_len(skb) is used from:
bpf_skb_adjust_room
__bpf_skb_change_tail
__bpf_skb_change_head
but in the case of forwarding we're likely calling these functions
during receive processing on ingress and bpf_redirect()'ing at
a later point in time to egress on another interface, thus these
mtu checks are for the wrong device (input instead of output).
This is particularly problematic if we're receiving on an L3 1500 mtu
cellular interface, trying to add an L2 header and forwarding to
an L3 mtu 1500 mtu wifi/ethernet device (which is thus L2 1514).
The mtu check prevents us from adding the 14 byte ethernet header prior
to forwarding the packet.
After the packet has already been redirected, we'd need to add
an additional 2nd ebpf program on the target device's egress tc hook,
but then we'd also see non-redirected traffic and have no easy
way to tell apart normal egress with ethernet header packets
from forwarded ethernet headerless packets.
Link: https://patchwork.ozlabs.org/project/netdev/patch/20200507023606.111650-1-zenczykowski@gmail.com/
But note that a more thorough solution will be pursued.
CRs-Fixed: 2662725
Bug: 149816401
Change-Id: If55a144d7822e23bce85f65897bca7de4e0f9b24
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Git-commit: af2b56c502d697a237757aa36b5d5523b29702fa
Git-repo: https://android.googlesource.com/kernel/common/
Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
AB voting is done in multiples of BW_STEP. Using a big
BW_STEP can result in AB overvoting because of roundup.
Use BW_STEP as 50 instead of 160. This will reduce AB
overvoting and will improve power.
Change-Id: Ieff338685be9650218fd7accc4ed3bcf0d2756ec
Signed-off-by: Deepak Kumar <dkumar@codeaurora.org>