ipv6: add option to drop unsolicited neighbor advertisements

In certain 802.11 wireless deployments, there will be NA proxies
that use knowledge of the network to correctly answer requests.
To prevent unsolicitd advertisements on the shared medium from
being a problem, on such deployments wireless needs to drop them.

Enable this by providing an option called "drop_unsolicited_na".

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit aec215e7aa380fe5f85eb6948766b58bf78cb6c3)

Change-Id: Iad429a767a786087b0985632be44932b2e3fd1a8

ipv4: add option to drop gratuitous ARP packets

In certain 802.11 wireless deployments, there will be ARP proxies
that use knowledge of the network to correctly answer requests.
To prevent gratuitous ARP frames on the shared medium from being
a problem, on such deployments wireless needs to drop them.

Enable this by providing an option called "drop_gratuitous_arp".

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 4078228159c9f54cca7347a8bdace29f2abdef65)

Change-Id: I8772dbd7471085878f8b4161eb2a056d79b8b232

ipv6: add option to drop unicast encapsulated in L2 multicast

In order to solve a problem with 802.11, the so-called hole-196 attack,
add an option (sysctl) called "drop_unicast_in_l2_multicast" which, if
enabled, causes the stack to drop IPv6 unicast packets encapsulated in
link-layer multi- or broadcast frames. Such frames can (as an attack)
be created by any member of the same wireless network and transmitted
as valid encrypted frames since the symmetric key for broadcast frames
is shared between all stations.

Reviewed-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit dede82143bf1bbf92ea73a519bb0298b19c56cb9)

Change-Id: I76c8f84b53e95c40ad3c2b5adac0ec4964cc920c

ipv4: add option to drop unicast encapsulated in L2 multicast

In order to solve a problem with 802.11, the so-called hole-196 attack,
add an option (sysctl) called "drop_unicast_in_l2_multicast" which, if
enabled, causes the stack to drop IPv4 unicast packets encapsulated in
link-layer multi- or broadcast frames. Such frames can (as an attack)
be created by any member of the same wireless network and transmitted
as valid encrypted frames since the symmetric key for broadcast frames
is shared between all stations.

Additionally, enabling this option provides compliance with a SHOULD
clause of RFC 1122.

Change-Id: I8de9fa5bdbea0556802f2ee553d0e73c1349213e
Reviewed-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

fs/exec: fix use after free in execve

"file" can be already freed if bprm->file is NULL after
exec_binprm() return. binfmt_script will do exactly that for
example. If the VM reuses the file after fput run(), this will result in
a use ater free.

So obtain d_is_su before exec_binprm() runs.

This should explain this crash:

[25333.009554] Unable to handle kernel NULL pointer dereference at virtual address 00000185
[..]
[25333.009918] [2:             am:21861] PC is at do_execve+0x354/0x474

Change-Id: I2a8a814d1c0aa75625be83cb30432cf13f1a0681
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>

kernel: Fix potential refcount leak in su check

Change-Id: I8d2c8bed65a01eb0928308df638a04449a5bd881

kernel: Only expose su when daemon is running

It has been claimed that the PG implementation of 'su' has security
vulnerabilities even when disabled.  Unfortunately, the people that
find these vulnerabilities often like to keep them private so they
can profit from exploits while leaving users exposed to malicious
hackers.

In order to reduce the attack surface for vulnerabilites, it is
therefore necessary to make 'su' completely inaccessible when it
is not in use (except by the root and system users).

Change-Id: I79716c72f74d0b7af34ec3a8054896c6559a181d

Revert "f_fs: set maxburst to one before enabling endpoints"

This reverts commit e3c2d0c27e3bd3df4b66bba9e9b47c7e0a442eb8.

This was severely slowing down usb transfer speeds.

Bug: 76154677
Test: mtp and adb speeds return to normal
Change-Id: I70e7a45b3d71a66a4191637891d145a86495aab6
Signed-off-by: Jerry Zhang <zhangjerry@google.com>

ANDROID: usb: gadget: f_accessory: Also zero out rx_req on unbind

Prevents crash in the following sequence:

successful bind initializes all elements of rx_req
unbind frees all elements of rx_req but doesn't zero out rx_req
bind() -> failed create_bulk_endpoints() on allocating rx_req[0], tries
to free all elements of rx_req, double free on rx_req[1]

Bug: 73769117
Test: no crash
Change-Id: I69c538450ea52a1aa718d27a2a48629f66a7e8b6
Signed-off-by: Jerry Zhang <zhangjerry@google.com>

ANDROID: usb: gadget: f_accessory: Fix double-free

Set the request to null to avoid double free in
retry_rx_alloc.

Bug: 73645054
Test: no double free
Change-Id: Iecf22c807a4a23b4b2ba7ebee53c53502c616ec5
Signed-off-by: Jerry Zhang <zhangjerry@google.com>

ANDROID: usb: gadget: f_accessory: Increase buffer size and max burst

Requests begin with large buffers for performance, and
the buffers are halved if allocation fails.

Bug: 67683483
Change-Id: I63d9f18385ca8e86894fd75d80c1702ee3e4e25f
Signed-off-by: Jerry Zhang <zhangjerry@google.com>

usb: gadget: f_fs: Fix possibe deadlock

commit b3ce3ce02d146841af012d08506b4071db8ffde3 upstream.

When system try to close /dev/usb-ffs/adb/ep0 on one core, at the same
time another core try to attach new UDC, which will cause deadlock as
below scenario. Thus we should release ffs lock before issuing
unregister_gadget_item().

[   52.642225] c1 ======================================================
[   52.642228] c1 [ INFO: possible circular locking dependency detected ]
[   52.642236] c1 4.4.6+ #1 Tainted: G        W  O
[   52.642241] c1 -------------------------------------------------------
[   52.642245] c1 usb ffs open/2808 is trying to acquire lock:
[   52.642270] c0  (udc_lock){+.+.+.}, at: [<ffffffc00065aeec>]
usb_gadget_unregister_driver+0x3c/0xc8
[   52.642272] c1  but task is already holding lock:
[   52.642283] c0  (ffs_lock){+.+.+.}, at: [<ffffffc00066b244>]
ffs_data_clear+0x30/0x140
[   52.642285] c1 which lock already depends on the new lock.
[   52.642287] c1
               the existing dependency chain (in reverse order) is:
[   52.642295] c0
       -> #1 (ffs_lock){+.+.+.}:
[   52.642307] c0        [<ffffffc00012340c>] __lock_acquire+0x20f0/0x2238
[   52.642314] c0        [<ffffffc000123b54>] lock_acquire+0xe4/0x298
[   52.642322] c0        [<ffffffc000aaf6e8>] mutex_lock_nested+0x7c/0x3cc
[   52.642328] c0        [<ffffffc00066f7bc>] ffs_func_bind+0x504/0x6e8
[   52.642334] c0        [<ffffffc000654004>] usb_add_function+0x84/0x184
[   52.642340] c0        [<ffffffc000658ca4>] configfs_composite_bind+0x264/0x39c
[   52.642346] c0        [<ffffffc00065b348>] udc_bind_to_driver+0x58/0x11c
[   52.642352] c0        [<ffffffc00065b49c>] usb_udc_attach_driver+0x90/0xc8
[   52.642358] c0        [<ffffffc0006598e0>] gadget_dev_desc_UDC_store+0xd4/0x128
[   52.642369] c0        [<ffffffc0002c14e8>] configfs_write_file+0xd0/0x13c
[   52.642376] c0        [<ffffffc00023c054>] vfs_write+0xb8/0x214
[   52.642381] c0        [<ffffffc00023cad4>] SyS_write+0x54/0xb0
[   52.642388] c0        [<ffffffc000085ff0>] el0_svc_naked+0x24/0x28
[   52.642395] c0
              -> #0 (udc_lock){+.+.+.}:
[   52.642401] c0        [<ffffffc00011e3d0>] print_circular_bug+0x84/0x2e4
[   52.642407] c0        [<ffffffc000123454>] __lock_acquire+0x2138/0x2238
[   52.642412] c0        [<ffffffc000123b54>] lock_acquire+0xe4/0x298
[   52.642420] c0        [<ffffffc000aaf6e8>] mutex_lock_nested+0x7c/0x3cc
[   52.642427] c0        [<ffffffc00065aeec>] usb_gadget_unregister_driver+0x3c/0xc8
[   52.642432] c0        [<ffffffc00065995c>] unregister_gadget_item+0x28/0x44
[   52.642439] c0        [<ffffffc00066b34c>] ffs_data_clear+0x138/0x140
[   52.642444] c0        [<ffffffc00066b374>] ffs_data_reset+0x20/0x6c
[   52.642450] c0        [<ffffffc00066efd0>] ffs_data_closed+0xac/0x12c
[   52.642454] c0        [<ffffffc00066f070>] ffs_ep0_release+0x20/0x2c
[   52.642460] c0        [<ffffffc00023dbe4>] __fput+0xb0/0x1f4
[   52.642466] c0        [<ffffffc00023dd9c>] ____fput+0x20/0x2c
[   52.642473] c0        [<ffffffc0000ee944>] task_work_run+0xb4/0xe8
[   52.642482] c0        [<ffffffc0000cd45c>] do_exit+0x360/0xb9c
[   52.642487] c0        [<ffffffc0000cf228>] do_group_exit+0x4c/0xb0
[   52.642494] c0        [<ffffffc0000dd3c8>] get_signal+0x380/0x89c
[   52.642501] c0        [<ffffffc00008a8f0>] do_signal+0x154/0x518
[   52.642507] c0        [<ffffffc00008af00>] do_notify_resume+0x70/0x78
[   52.642512] c0        [<ffffffc000085ee8>] work_pending+0x1c/0x20
[   52.642514] c1
              other info that might help us debug this:
[   52.642517] c1  Possible unsafe locking scenario:
[   52.642518] c1        CPU0                    CPU1
[   52.642520] c1        ----                    ----
[   52.642525] c0   lock(ffs_lock);
[   52.642529] c0                                lock(udc_lock);
[   52.642533] c0                                lock(ffs_lock);
[   52.642537] c0   lock(udc_lock);
[   52.642539] c1
                      *** DEADLOCK ***
[   52.642543] c1 1 lock held by usb ffs open/2808:
[   52.642555] c0  #0:  (ffs_lock){+.+.+.}, at: [<ffffffc00066b244>]
ffs_data_clear+0x30/0x140
[   52.642557] c1 stack backtrace:
[   52.642563] c1 CPU: 1 PID: 2808 Comm: usb ffs open Tainted: G
[   52.642565] c1 Hardware name: Spreadtrum SP9860g Board (DT)
[   52.642568] c1 Call trace:
[   52.642573] c1 [<ffffffc00008b430>] dump_backtrace+0x0/0x170
[   52.642577] c1 [<ffffffc00008b5c0>] show_stack+0x20/0x28
[   52.642583] c1 [<ffffffc000422694>] dump_stack+0xa8/0xe0
[   52.642587] c1 [<ffffffc00011e548>] print_circular_bug+0x1fc/0x2e4
[   52.642591] c1 [<ffffffc000123454>] __lock_acquire+0x2138/0x2238
[   52.642595] c1 [<ffffffc000123b54>] lock_acquire+0xe4/0x298
[   52.642599] c1 [<ffffffc000aaf6e8>] mutex_lock_nested+0x7c/0x3cc
[   52.642604] c1 [<ffffffc00065aeec>] usb_gadget_unregister_driver+0x3c/0xc8
[   52.642608] c1 [<ffffffc00065995c>] unregister_gadget_item+0x28/0x44
[   52.642613] c1 [<ffffffc00066b34c>] ffs_data_clear+0x138/0x140
[   52.642618] c1 [<ffffffc00066b374>] ffs_data_reset+0x20/0x6c
[   52.642621] c1 [<ffffffc00066efd0>] ffs_data_closed+0xac/0x12c
[   52.642625] c1 [<ffffffc00066f070>] ffs_ep0_release+0x20/0x2c
[   52.642629] c1 [<ffffffc00023dbe4>] __fput+0xb0/0x1f4
[   52.642633] c1 [<ffffffc00023dd9c>] ____fput+0x20/0x2c
[   52.642636] c1 [<ffffffc0000ee944>] task_work_run+0xb4/0xe8
[   52.642640] c1 [<ffffffc0000cd45c>] do_exit+0x360/0xb9c
[   52.642644] c1 [<ffffffc0000cf228>] do_group_exit+0x4c/0xb0
[   52.642647] c1 [<ffffffc0000dd3c8>] get_signal+0x380/0x89c
[   52.642651] c1 [<ffffffc00008a8f0>] do_signal+0x154/0x518
[   52.642656] c1 [<ffffffc00008af00>] do_notify_resume+0x70/0x78
[   52.642659] c1 [<ffffffc000085ee8>] work_pending+0x1c/0x20

Change-Id: I4f084295389670cab0f7b7ee2d866e263f09f6da
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Cc: Jerry Zhang <zhangjerry@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Revert "serial: msm_serial_hs: Protect spurious irqs after wakeup irq enablement"

This reverts commit 545339b82c446a0509e775722b675115241c9f57.

This workaround is no longer needed because pinctrl IRQ chip driver has been fixed
to clear spurious interrupts:
https://partner-android-review.googlesource.com/c/kernel/private/msm-google/+/1070357/

Bug: 68261352
Bug: 77429706
Change-Id: I66400003a04f50f22033f80fe31ef81ce622cfc1
Signed-off-by: Petri Gynther <pgynther@google.com>

Revert "Revert "select: use freezable blocking call""

This reverts commit 59612d187912750f416fbffe0c00bc0811c54ab5.

Android doesn't need to worry about buggy i686 implementations, which
was the reason behind the original revert.

See https://bugzilla.kernel.org/show_bug.cgi?id=61781.

Test: device enters suspend and everything works fine
bug 77139736

Change-Id: I84dd94d3cc8624293f10d0904c189ca63ecbe3d8
Signed-off-by: Tim Murray <timmurray@google.com>

Revert "usb: hub: Prevent hub autosuspend if usbcore.autosuspend is -1"

Certain USB-C devices are failing to enumerate if the bus
transitions from active to suspend between connection and enumeration.

When a USB-C accessory is inserted in a phone and is detected by the
CC lines, the controller driver is loaded and the only devices present
on the bus are the root hubs, until the device enumerations.
As a result, a suspend transition between device connection and
enumeration is very likely.

This change leaves the hub autosuspend set to the usbcore.autosuspend
value so a value can be set high enough to prevent this race.

This reverts:
commit bdd405d2a528 ("usb: hub: Prevent hub autosuspend if usbcore.autosuspend is -1")

  If user specifies that USB autosuspend must be disabled by module
  parameter "usbcore.autosuspend=-1" then we must prevent
  autosuspend of USB hub devices as well.

  commit 596d789a211d introduced in v3.8 changed the original behaivour
  and stopped respecting the usbcore.autosuspend parameter for hubs.

Bug: 71936484
Change-Id: Ie20471b9e8d44f92f9eff97ed12ccd903c98c272
Signed-off-by: Thierry Strudel <tstrudel@google.com>
Signed-off-by: Andrew Chant <achant@google.com>

BACKPORT: usb: host: plat: Enable xHCI plat runtime PM

Enable the xHCI plat runtime PM for parent device to
suspend/resume xHCI.

https://patchwork.kernel.org/patch/9679003/

Leaving out the pm_runtime_forbid() as autosuspend
seems to be enabled in qualcomm's code.

BUG: 63697798

Change-Id: I5c1ce3ccc0a70cddce9c68def30c7bc54165f479
Signed-off-by: Badhri Jagan Sridharan <Badhri@google.com>

ASoC: msm: q6dspv2: vote for Glink Rx thread priority upgrade

For Low-latency audio playback usecase, vote for a priority
upgrade for Glink Rx thread, to avoid any performance issue.

Bug: 38234822
Change-Id: I8332c80eedd7325700e695f341fc4b92f65fd77c
Signed-off-by: Banajit Goswami <bgoswami@codeaurora.org>

genirq: Add generic action name for chained IRQs

Chained IRQs (the local device IRQs for chips that relay other IRQs)
are all initialized in the kernel using a shared generic irqaction
struct called "chained_action".  Since the action is shared, the API
for registering chained IRQ handlers does not allow a unique name to
be specified, whereas non-chained IRQ handlers can have unique names.

Unfortunately, the name of an IRQ handler action is included in resume
logging, both in the kernel and in batterystats, and the name of the
shared action for chained IRQ handlers is left null.  So when a chained
IRQ is detected as part of the wakeup reason during resume flow, we
currently see log content like "10 triggered null" and "Resume caused
by IRQ 10" in the kernel log and wakeup reason substrings like ":10:"
in batterystats.

To reduce confusion when troubleshooting and improve the clarity of
logs, this change adds a generic name ("chained-irq") to the shared
action.  This name will show up in resume logging whenever any chained
IRQ handler is part of the wakeup reason.  In the kernel log:
"10 triggered null" will become "10 triggered chained-irq"
"... caused by IRQ 199" will become "... caused by IRQ 199 chained-irq"
And in batterystats wakeup reasons:
":10:" will become ":10:chained-irq"

This change does not (and cannot) provide any clarity in the logs
about which chip is associated with which chained IRQ number; that
information - if needed - must be obtained through other means.

Bug: 63899519
Test:Ran on walleye and taimen devices and observed kernel logging
and dumpsys batterystats logging changes.
Signed-off-by: Kelly Rossmoyer <krossmo@google.com>
Change-Id: I807f385fe64573cb3962cd25089fbc8e270a2377

power: Improved/fixed logs for PM wakeups

PM wakeups were reporting in kernel and BatteryStats logs as abort
suspends due to the PM IRQ handler logging a suspend abort, which
prevented the normal wakeup resume messaging. Suspend abort reasons
are already logged in pm_wakeup_pending() in
drivers/base/power/wakeup.c.

Bug: 34225014
Change-Id: I8b9ab597caef61b0d6f5b853b2947d6afc13d693
Signed-off-by: Maggie White <maggiewhite@google.com>

power_supply: Fix unbalanced the power supplies

If a driver invokes multiple power_supply_register(), the each supply
will not be saved in the supplied_from[] with the correct index.

supplied_from[0] = "dc"
num_supplies = 1;

supplied_from[0] = "usb"
num_supplies = 2;

supplied_from[0] = "battery"
num_supplies = 3;
...

It results in NPE when iterating the supplied_from[] with num_supplies on
__power_supply_is_supplied_by()

Bug: 63785418
Change-Id: Ifd14ca7c6e2df247e1090e4fa8d8c66bd2912180
Signed-off-by; Devin Kim <dojip.kim@lge.com>
Signed-off-by: Steve Pfetsch <spfetsch@google.com>

fs: Improve eventpoll logging to stop indicting timerfd

timerfd doesn't create any wakelocks; eventpoll can, and is creating the
wakelocks we see called "[timerfd]".  eventpoll creates two kinds of
wakelocks: a single top-level lock associated with the eventpoll fd
itself, and one additional lock for each fd it is polling that needs such
a lock (e.g. those using EPOLLWAKEUP).  Current code names the per-fd
locks using the undecorated names of the fds' associated files (hence
"[timerfd]"), and is naming the top-level lock after the PID of the caller
and the name of the file behind the first fd for which a per-fd lock is
created.  To make things clearer, the top-level lock is now named using
the caller PID and an "epollfd" designation, while the per-fd locks are
also named with the caller's PID (to associate them with the top-level
lock) and their respective fds' file names.

Bug: 63622255
Bug: 38042165
Test: Ran on device and observed new wakelock naming in bugreport, dumpsys
batterystats, /d/tracing/trace, and d/wakeup_reasons.
Change-Id: I32bfe5fe6766bb569329a450cc7163d52d59ed34
Signed-off-by: Kelly Rossmoyer <krossmo@google.com>

fs: add useful debug info to eventpoll string

Add pid and file to facilitate debugging when eventpoll wakeup
prevents sleeping.

Bug: 32180327
Change-Id: I34bada5ddab04cf3830762c745f46bfcd1549cb8
Signed-off-by: John Dias <joaodias@google.com>

PM: wakeup_reasons: Fix formatting for printk

current output looks like this:

[  133.772467] Abort: Wakeup IRQ 730 wdog-bark pending[  133.777343] PM: suspend exit 2017-11-30 19:05:34.974168313 UTC

Change it to this:

[  133.772467] Abort: Wakeup IRQ 730 wdog-bark pending
[  133.777343] PM: suspend exit 2017-11-30 19:05:34.974168313 UTC

Change-Id: Ic38338a3274b83256788077db6f1040605b79603
Signed-off-by: Patrick Tjin <pattjin@google.com>

power: Add detailed suspend abort reason

Test: dumpsys batterystats
Bug: 30874086

(cherry picked from commit a9d6bead120dab67e00bfe5500a616f83b94cf44)

Change-Id: I9feae71693b4addd45550b19ecab7dfd7371c378
Signed-off-by: Maggie White <maggiewhite@google.com>

power: wakeup_reason: make log function work in interrupt context

If log_suspend_abort_reason called in interrupt context, the spinlock
may deadlock.
With https://lkml.org/lkml/2014/9/1/404, wakeup mechanism changed, so
log_suspend_abort_reason can be placed in interrupt context to retrieve
the abort reasons.

Bug: 32371978
Change-Id: I6902770e54b663d21b47289daec19401fc0dbed4
Signed-off-by: Wei Wang <wvw@google.com>

irqchip: msm: log wakeup interrupts

set msm_show_resume_irq_mask to log wakeup reasons for batterystats

Bug: 28383208
Change-Id: I00b856c691d9da7ed6452704db9b0f3f56f49581
Signed-off-by: Thierry Strudel <tstrudel@google.com>

pinctrl: qcom: unconditionally mark handled in msm_gpio_irq_handler

Current accounting is innaccurate for lazy irq masking and may
cause handle_bad_irq triggered in such case.

Bug: 30604869
Change-Id: If805e10c724b755323004da1e1fe18d315e81df2
Signed-off-by: Wei Wang <wvw@google.com>

pinctrl: qcom: log wakeup reason

Bug: 29697729
Change-Id: Id25487ba6ba4f141dff3653089a100931bd4fb71
Signed-off-by: Thierry Strudel <tstrudel@google.com>

irq: Add wakeup reason logging

log wakeup reason for irq

Bug: 28852315
Change-Id: Iad9cf7423e51441c81f52fd94dd6347de6709262
Signed-off-by: Wei Wang <wvw@google.com>

BACKPORT: PM: wakeup_reasons: disable wakeup-reason deduction by default

Introduce a config item, CONFIG_DEDUCE_WAKEUP_REASONS, disabled by default.
Make CONFIG_PARTUALRESUME select it.

(cherry picked from commit 753b5405eedf67357952e3a10cb3fb1392a3972b)
Change-Id: I7d831ff0a9dfe0a504824f4bc65ba55c4d92546b
Signed-off-by: Iliyan Malchev <malchev@google.com>

PM: wakeup_reasons: fix race condition

log_possible_wakeup_reason() and stop_logging_wakeup_reasons() can race, as the
latter can be called from process context, and both can run on separate cores.

Change-Id: I306441d0be46dd4fe58c55cdc162f9d61a28c27d
Signed-off-by: Iliyan Malchev <malchev@google.com>

BACKPORT: PM: wakeup_reason: add functions to query and clear wakeup reasons

The query results are valid until the next PM_SUSPEND_PREPARE.

(cherry picked from commit 76543de14f860ab713114621cb62e8006b7ca952)
Change-Id: I6bc2bd47c830262319576a001d39ac9a994916cf
Signed-off-by: Iliyan Malchev <malchev@google.com>

pinctrl/qcom: pinctrl-msm.c: Bypass GPIO pins owned by TZ

Accessing pins owned by TZ crashes the system. Avoid to access these
pins in msm_gpio_dbg_show so that we can cat "/d/gpio" to monitor pin
states without crash.

Bug: 34906817
Change-Id: Ib5347dee882299361094e31cfb7950b65716e654
Signed-off-by: Woody Lin <woody_lin@htc.com>

ANDROID: pstore: Use vmalloc for large allocations due to ramoops size

Android uses a 1 MiB console ramoops region, which requires kmalloc
to be changed to vmalloc in the following places:

1. pstore_mkfile(), allocation of inode->i_private
2. ramoops_pstore_read(), allocation of buf

Bug: 67383905
Change-Id: Ie4f355a5991b7cb6ad356ded7bd9d41630602bf5
Signed-off-by: Siqi Lin <siqilin@google.com>

ANDROID: fs/pstore/ramoops: Use vmalloc() for old buffer

console-ramoops size can be big enough for kmalloc() to
fail due to memory fragmentation. Use vmalloc() instead.

Bug: 65495856
Change-Id: I28c7ba97e8ebfd6b8f4ebfe9296a2d76fa6e2652
Signed-off-by: Siqi Lin <siqilin@google.com>

serial: msm_serial_hs: Protect spurious irqs after wakeup irq enablement

This patch protects against unknown spurious signals generated on Rx
line.
The possible sources of spurious signals are unknown as of now.
Yes, 1 msec delay after enabling wakeup interrupt to suppress false call
to ISR handlers which we do not expect.
In case of shutdown, we do not expect wake up irq to get fired as irq
gets disabled in the start.

Change-Id: I3cb34e5c39bff715cad1618c2eeefbf9bc95c87c
Signed-off-by: Mukesh Kumar Savaliya <msavaliy@codeaurora.org>

tty:  check before stopping kthread

Kthread allocation can fail, so check that it's not an error value
before trying to stop it.

Bug: 63354008
Test: build & run bluetooth audio
Signed-off-by: Philip Cuadra <philipcuadra@google.com>
Change-Id: Ia8a91645beef2b4df64582b9059272f6df8ad4a9

msm_serial_hs: make the Bluetooth tty thread RT

For Bluetooth, the tty kthread should be RT in order to avoid scheduling
delays.

Bug: 36106419
Test: play bluetooth audio, verify tty kthread runs at RT via systrace
Change-Id: I441dd10d22f8831d055166bcd1ff9f01e5ca13d4
Signed-off-by: Philip Cuadra <philipcuadra@google.com>

tty: add tty_port_set_policy function

This function allows the port's scheduling policy to be changed.  Some
tty ports (like Bluetooth ones), need a higher priority to reduce
jitter.

Bug: 36106419
Test:  Bluetooth audio
Change-Id: If11e21c55924314910d602573c735c6afae09709
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tty: move tty_port workqueue to be a kthread

This makes each tty_port have their own kthread, hopefully allowing them
a bit more freedom in scheduling when they reveive data.

Based on a patch from Philip Cuadra <philipcuadra@google.com>
Based on a patch from Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bug: 36106419
Test: run Bluetooth audio, ensure separate tty thread is created.
Signed-off-by: Philip Cuadra <philipcuadra@google.com>
Change-Id: I9fd25235b26a66acb37a40304c356209b74ad46c

Make msm_serial_hs RT to improve bluetooth performance

msm_serial_hs threads for RX and TX are responsible for passing key
bluetooth buffers, such as bluetooth audio, between the Bluetooth HW and
the upper layers of the stack.  These threads are therefore on the
critical path for bluetooth audio latency, and should be scheduled as
RT threads in order to ensure that they meet audio deadlines.

Bug 36106419

Test:  Play bluetooth audio, confirm msm_serial_hs_0 threads are
scheduled as RT threads via systrace
Change-Id: I078dbcbab189a03bdc5fdfde6ec8c41c79c11610
Signed-off-by: Philip Cuadra <philipcuadra@google.com>

thermal: tsens: Disable tsens_poll_check for msm8998

Change-Id: I7f9c9f63fe2987c5b75773d87fde26e263c5ac71

smp: Wake up all idle CPUs when suspending to idle

Regardless of CPU isolation or not, we need to wake up all the
CPUs during suspend to idle so that each CPU can disable their
local tick device, etc. If we don't wake every CPU up, then we
don't fully suspend the system and things like sched_clock and
timekeeping are never stopped properly.

Change-Id: Ic9141602acc5e6cddefca0727f9be075dad3e498
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>

sched: set loop_max after rq lock is taken

While doing a load balance there is a race in setting
loop_max variable since nr_running can be changed causing
incorect iteration loops.

As a result we may skip some candidates or check the same
tasks again.

Change-Id: I2f58f8fe96c14bd70674e600bc33caeb8aa960c6
Signed-off-by: Uladzislau 2 Rezki <uladzislau2.rezki@sonymobile.com>
Signed-off-by: Artem Labazov <123321artyom@gmail.com>

workqueue: add cancel_work()

Like cancel_delayed_work(), but for regular work.

Change-Id: Ic967cb1616245b71a63e1b92f8e28d94a27ae490
Signed-off-by: Jens Axboe <axboe@fb.com>
Mehed-by: Tejun Heo <tj@kernel.org>
Acked-by: Tejun Heo <tj@kernel.org>

drivers: thermal: Use deferrable work and power efficient workqueue

Thermal core uses work events to poll for sensor driver temperature
crossing a threshold. Since it is not using a deferrable workqueue, it
might wake-up the device from sleep.

Use a deferrable work event and post the work in the power efficient
workqueue for estimating virtual sensor temperature.

Change-Id: I9dd21d8fc4e5ca96e06db9ecb57a628618494a01
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>

drivers: thermal: Use high priority work queue for thermal processing

Thermal framework uses system freezable work queue for processing the
governor action and mitigation action will be performed in the same
context. System work queue can have one max active event processing
and if the mitigation action is delayed, that will bottleneck the
rest of the work queue event processing. This will result in delayed
action and temperature overshoot.

To avoid this, a new high priority thermal work queue is created and all
the passive monitoring will be done in the high priority context. Also
this work queue has a max active count defined as 16, which will allow
multi-processing of work events.

Change-Id: Id506f21c1583e0ba2e022f8b7bc28e3972c592ef
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>

BACKPORT: mm: fix pageblock heuristic

The Android-tuned page block heuristic was accidentally reset in an AU
drop. Fix the heuristic to avoid unnecessary unmovable pageblock
migration over time.

bug 30643938
Bug: 63336523
(cherry-picked from commit 3e19bcf7d08713daaaba888b4d13502e06e38e96)
Change-Id: I59efcd3934f29982b1c9aeb7b0f18eb17e0934b3
Signed-off-by: John Dias <joaodias@google.com>

trace: add CONFIG_DISABLE_TRACE_PRINTK option

Poorly made kernel trees often use trace_printk() without
properly guarding them in a #ifdef macro.
Such usage of trace_printk() causes a warning at
boot and additional memory allocation.

This option serves to disable those all at once with ease.

Change-Id: I2cb2085f48064bda8c18806597c5aee57237dca6
Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com>
Signed-off-by: Alex Naidis <alex.naidis@linux.com>

Revert "USB: core: only clean up what we allocated"

This reverts commit 33f11e4812d25d0709740fc0a52f9658d6f0ac61.

Alan wrote a better fix for this:
USB: core: prevent malicious bNumInterfaces overflow

Change-Id: I3410378b27479d0db51fed51c82806045274ecf8
Cc: Andrey Konovalov <andreyknvl@google.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

pinctrl: qcom: Add irq_enable callback for msm gpio

Introduce the irq_enable callback which will be same as irq_unmask
except that it will also clear the status bit before unmask.

This will help in clearing any erraneous interrupts that would
have got latched when the interrupt is not in use.

There may be devices like UART which can use the same gpio line
for data rx as well as a wakeup gpio when in suspend. The data that
was flowing on the line may latch the interrupt and when we enable
the interrupt before going to suspend, this would trigger the
unexpected interrupt. This change helps clearing the interrupt
so that these unexpected interrupts gets cleared.

Bug: 68261352
Bug: 77429706
Change-Id: I017badff8d5b993599d7e7240ed4702ff4b344ad
Signed-off-by: Srinivas Ramana <sramana@codeaurora.org>
Signed-off-by: Kyle Yan <kyan@codeaurora.org>
Signed-off-by: Mugata, Sreenivasa Rao <smugat@codeaurora.org>
Signed-off-by: Petri Gynther <pgynther@google.com>

drivers: pinctrl: mask non-wakeup interrupts in suspend path

Bug: 30079159
Change-Id: If66a7ab642d28c7a42e0af337e388af4c1915677

slimbus: Add missing brackets in slim_change_existing_chans

Change-Id: I2f13656d0e8aa18213b54314f19fcd33a96751c4

scsi: ufs: synchronize between rls handler and clock scaling

Fix race condition between rls handler thread and clock scaling thread when
LINERESET indication is sent out from host controller. A known scenario is
when clock scaling thread has put link to hibern8 after gear scaling down
is done, if rls handler thread, scheduled because of LINERESET indication
from controller, starts to run now to scale gear up (PWM to HS), it would
fail as the link state is still in hibern8 state. This change fixes this
race condition by using write semaphore to prevent rls handler thread and
clock scaling thread getting chance to run simultaneously.

Change-Id: Ia1731c921c42155cacb43029d56491ddffcf2ee2
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Can Guo <cang@codeaurora.org>

scsi: ufs: change the clock scaling polling period and up threshold

We have noticed that UFS load based clock scaling is ramping up to highest
frequency during low power usecases but never scales back to lower
frequency during the remaining usecase run period. This increases the
oveall power consumption for a given low power usecase. We analyzed UFS
data transfer pattern for different low power usecases and updated clock
scaling polling period & up threshold which helps with power numbers
without affecting performance numbers.

Change-Id: I74cf8a1f07d1b1a0ac112f28fc98a8a82cac1d28
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>

scsi: ufs: Avoid deadlock in suspend and eeh_work

In case of an exception, there could be a deadlock:

eeh_work:
-002|schedule()
-003|spin_lock_irq()
-003|rpm_resume << pm_runtime_get_sync(hba->dev);
-004|__pm_runtime_resume()
-005|ufshcd_scsi_block_requests()
-005|ufshcd_exception_event_handler()

ufshcd_suspend:
-002|schedule()
-003|schedule_timeout()
-004|do_wait_for_common()
-004|__wait_for_common()
-004|wait_for_common()
-005|wait_for_completion()
-006|destroy_work_on_stack()
-006|flush_work(?) << eeh_work
-007|ufshcd_suspend()
-008|ufshcd_runtime_suspend()
-009|ufshcd_pltfrm_runtime_suspend()
-010|pm_generic_runtime_suspend()
-011|__rpm_callback()

Scenario looks like :
1.Hba->eeh_work starts to work and at the almost same
time ufshcd_runtime_suspend start to work by rpm core.
2.pm_runtime_get_sync in eeh_work remains pending as
rpm_status is RPM_SUSPENDING due to ufshcd_runtime_suspend.

To fix this, call pm_runtime_get_noresume() once eeh_work
is scheduled so that suspend cannot be invoked during
exception work.

Change-Id: Ib212f71e22f063dad9c6ccca4aa8f7261e568b51
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org>

Fix bugs about step-chg-jeita

1. JEITA FV compensation cannot work
2. Cannot charge when battery capacity is 0%
3. Wrong debug message

Change-Id: I32ecb77b4c1dd8073cbf5aec070c3e6fcadc1dd2

ASoC: msm-cpe: Fix msm_cpe_lsm_ioctl_compat error handling

Change-Id: Iec6a12aaed4dce60f774c09264b8e566a17ce9d9

Silences WLAN, PCIe, and CPU suspend state kernel messages

Bug: 27134656
Change-Id: I681ec2171472514489365ca4bfc4ef16d9b344fe

PM / devfreq: bw_hwmon: Add missing mutex unlock

Fixes 28aab0311cfcd9b279f41f2f4da0085a660d5ed5
"PM/devfreq: bw_hwmon: add mutex lock in polling interval case"

Change-Id: I84ccefedbc9d9c0d25806799451346b6a46bae90

PM / devfreq: memlat: Don't ignore extremely latency sensitive workloads

The ratio value that's compared against ratio_ceil tunable can be 0 for
workloads that are extremely latency sensitive. So, we can't ignore cores
that have a ratio of 0 (which was done to ignore idle cores). So, stop
ignoring cores with a ratio of 0 and instead check for instruction or
frequency being 0 to identify idle cores.

Change-Id: I8c6c14f374f016e6612c3b834589d065bad8f488
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>

PM / devfreq: bw_hwmon: use unsigned parameter for bytes_to_mbps

In bytes_to_mbps function, the parameter is all unsigned,
so change the decleration of the function to include unsigned long
long to avoid compilation errors in 32 bit environment.
Also changed the return value as unsigned long to avoid
any data loss possible in 64 bit environment.

Change-Id: Ib3906bb4bc16086ae343764c5a718f6f005428c5
Signed-off-by: Maria Yu <aiquny@codeaurora.org>

drivers: cpuidle: lpm-levels: Reset suspend wake time

During suspend alarm timer sends next wakeup time to
be programmed. Currently next wakeup time is not reset
upon wakeup. This causes unintended wakeups if there is
no alarm set during next suspend.

Reset suspend wake time during exit from suspend.

Change-Id: Ia0e5d08a4e5cdc71f6c2d884363b830de5ef88d5
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>

cpuidle: lpm-levels: Do not predict LPM for isolated cpus

Prediction can select shallower low power mode for isolated
cpu based on historical data.

Do not predict LPMs for isolated cpus.

Change-Id: I998008ef3c578c1dccfacae8513a15dfbe397e16
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>

lpm_levels: Return true for CPU WFI mode allow check

As it's a general understanding across all architectures to have
a WFI (or equalivalent) mode always present and never disabled
for cpuidle, return true for CPU WFI mode allow check.

Change-Id: Ic55571488f845e4aaf997faaac3b2e0f22368d4e
Signed-off-by: Srinivas Rao L <lsrao@codeaurora.org>

binder: Disable debug mask

According to Google we should set this to 0
as there is excessive logging in specific usecases
which has a negative impact on latency.

Change-Id: If03401694c2b746b5e2111cb5daafa8eab169e29
Signed-off-by: Alex Naidis <alex.naidis@linux.com>

ANDROID: binder: Switch binder_deferred_lock to a spinlock.

Avoid delays in binder transactions due to preemption of
binder_deferred_func() with binder_deferred_lock held.

Bug: 66914906
Test: boots; binder tests pass; trace analysis in bug
Change-Id: I1a89ba15b27e43552890292f135a5e2d969231e2
Signed-off-by: Corey Tabaka <eieio@google.com>

cpu: Silence log spam when a CPU is brought up

Change-Id: Ib9bc76270fedb8d620714faf45de58d5ecdcd64e
Signed-off-by: Sultanxda <sultanxda@gmail.com>

cfq: Give a chance to arm slice idle timer in case of group_idle

In below scenario blkio cgroup does not work as per their assigned
weights :-
1. When the underlying device is nonrotational with a single HW queue
with depth of > 5
2. When the use case is forming two blkio cgroups cg1(weight 1000) &
cg2(wight 100) and two processes(file1 and file2) doing sync IO in
their respective blkio cgroups.

For above usecase result of fio (without this patch):-
file1: (groupid=0, jobs=1): err= 0: pid=685: Thu Jan  1 19:41:49 1970
  write: IOPS=1315, BW=41.1MiB/s (43.1MB/s)(1024MiB/24906msec)
<...>
file2: (groupid=0, jobs=1): err= 0: pid=686: Thu Jan  1 19:41:49 1970
  write: IOPS=1295, BW=40.5MiB/s (42.5MB/s)(1024MiB/25293msec)
<...>
// both the process BW is equal even though they belong to different
cgroups with weight of 1000(cg1) and 100(cg2)

In above case as soon as the request from cg1 is completed and even
though it is provided with higher slice_idle=10, because of CFQ
algorithm when the driver tries to fetch the request, CFQ expires
this group without providing any idle time nor weight priority
and schedules another cfq group (in this case cg2).
And thus both cfq groups(cg1 & cg2) keep alternating to get the
disk time and hence loses the cgroup weight based scheduling.

Below patch gives a chance to cfq algorithm (cfq_arm_slice_timer)
to arm the slice timer in case group_idle is enabled.

With this patch result of fio(for above usecase) :-
file1: (groupid=0, jobs=1): err= 0: pid=690: Thu Jan  1 00:06:08 1970
  write: IOPS=1706, BW=53.3MiB/s (55.9MB/s)(1024MiB/19197msec)
<..>
file2: (groupid=0, jobs=1): err= 0: pid=691: Thu Jan  1 00:06:08 1970
  write: IOPS=1043, BW=32.6MiB/s (34.2MB/s)(1024MiB/31401msec)
<..>
// In this processes BW is as per their respective cgroups weight.

Change-Id: I2eb20e48d6fd8ee48e01f00c514a1ee1476fd19c
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>

ion: ion_system_heap: update supported page-orders for ion pool

The supported mappings for ARMv8 are 1GB, 2MB, 64KB and 4KB. So 1MB
allocations from ion pool is not used for ARMv8 section map. Such
allocations end up being mapped as multiple 64K sections map, while still
using 1MB contiguous memory. In case of ARMv7s, page-order 9 allocations
are not used as section map.

Drop page-order 8 ion pool for builds using ARMv8 pagetables and page-order
9 ion pool for builds using ARMv7s.

Change-Id: Ifff2d8f1cf61ce443311d16c11b8edc191b27a22
Signed-off-by: Prakash Gupta <guptap@codeaurora.org>

msm: kgsl: Increase priority of RT thread

We need kgsl_worker_thread to preempt
all userspace surfaceflinger threads to
avoid a possible deadlock.

This will prevent the SF
threads from "stealing" cputime from
kgsl_worker_thread.
This is important, since kgsl_worker_thread
executes work which blocks SF from proceeding.

Change-Id: Ic4c9ca1f44ad8952ae2154a84ded7013244ca20d
Signed-off-by: Alex Naidis <alex.naidis@linux.com>

msm: kgsl: Stop slab shrinker when no more pages can be reclaimed

do_shrink_slab() scans each shrinker in batches of at most
batch_size (128) pages at a time until total_scan pages are
scanned or until shrinker returns SHRINK_STOP. Under heavy
memory pressure total_scan can be large (in thousands) and
kgsl_pool_shrink_scan_objects() ends up returning 0 after
all pages that were reclaimable are reclaimed. This results in
multiple calls to kgsl_pool_shrink_scan_objects() that do not
reclaim any memory. To prevent this kgsl_pool_shrink_scan_objects()
is modified to return SHRINK_STOP as soon as no more memory can
be reclaimed.

Bug: 69931996
Test: tested using alloc-stress with additional traces

Change-Id: Ia48fc2c0d888c54ec9642c0b0962a70ca3cb4c5e
Signed-off-by: Suren Baghdasaryan <surenb@google.com>

Revert "msm: kgsl: Do not memset pages to zero while adding to pool"

This reverts commit 90d6246fca5f288606551c5d02af920bfeb05b9b.

To address the launch latency issue seen because of increase in
memory allocation time.

Change-Id: I147ca8607337541b7a29056b4bd1b46aa374c6e3
Signed-off-by: Deepak Kumar <dkumar@codeaurora.org>

Revert "msm: kgsl: Disallow L2PC during wake up from SLUMBER"

This reverts commit 5344e5c78f5820dfa34cfcea4572d8e347a018ce.
The change negatively impacted performance.

CRs-Fixed: 2120475
Change-Id: Ib6ff329a3501e77d990c2e9502ed35e041f730c8
Signed-off-by: Kyle Piefer <kpiefer@codeaurora.org>

mfd: wcd9xxx: disable slimbus register access for debugfs

This patch disables default slimbus access exposed through debugfs.

Bug: 67430947
Change-Id: Iaf1b7cdf638dbc6e6de3681b8418f1840b94ccad
Signed-off-by: David Lin <dtwlin@google.com>

msm: mdss: fix inconsistent mutex_lock

drivers/video/fbdev/msm/mdss_mdp_splash_logo.c:480
mdss_mdp_splash_kickoff() warn: inconsistent returns
'mutex:&mdp5_data->ov_lock'

Change-Id: I3e97f80ff562bb0b260adeff733e78af1a8f1e67
Signed-off-by: David Lin <dtwlin@google.com>

msm: mdss: fix inconsistent mutex_lock

drivers/video/fbdev/msm/mdss_mdp_pp.c:4093 mdss_mdp_igc_lut_config()
warn: inconsistent returns 'mutex:&mdss_pp_mutex'

Change-Id: I956017162cde27fbaa3da5aeb28b76ec7308530e
Signed-off-by: David Lin <dtwlin@google.com>

slimbus: fix inconsistent mutex_lock

drivers/slimbus/slimbus.c:1331 slim_config_mgrports() warn: inconsistent
returns 'mutex:&ctrl->sched.m_reconf'

Change-Id: I023f69cc3496e9b98d9881c447fc1bf9053de97f
Signed-off-by: David Lin <dtwlin@google.com>

qdsp6v2: fix inconsistent mutex_lock

sound/soc/msm/qdsp6v2/q6voice.c:5984 voc_set_device_config() warn:
inconsistent returns 'mutex:&v->lock'

Change-Id: Ie58dbea8881acdd6a5253828e15d29075092b818
Signed-off-by: David Lin <dtwlin@google.com>

wcd9335: fix inconsistent mutex_lock

sound/soc/codecs/wcd9335.c:2608 slim_tx_mixer_put() warn: inconsistent
returns 'mutex:&tasha_p->codec_mutex'

Change-Id: I73d5331aa29155c85cce6940fe2b918cc7a445f6
Signed-off-by: David Lin <dtwlin@google.com>

msm: mdss: fix inconsistent mutex_lock

drivers/video/fbdev/msm/mdss_mdp_overlay.c:5280
__handle_overlay_prepare() warn: inconsistent returns
'mutex:&mdp5_data->ov_lock'

Change-Id: Iac6acb5fb84331949637258a55733b8be94690eb
Signed-off-by: David Lin <dtwlin@google.com>

msm: qdsp6v2: fix inconsistent spin_lock

sound/soc/msm/qdsp6v2/msm-lsm-client.c:334 lsm_event_handler() warn:
inconsistent returns 'spin_lock:&prtd->event_lock'

sound/soc/msm/qdsp6v2/msm-lsm-client.c:1635 msm_lsm_ioctl_compat() warn:
inconsistent returns 'mutex:&prtd->lsm_api_lock'

sound/soc/msm/qdsp6v2/msm-lsm-client.c:1914 msm_lsm_ioctl() warn:
inconsistent returns 'mutex:&prtd->lsm_api_lock'

Change-Id: Id1f754702a56ef21952c7f7bc8cf3ebd0a0ebefa
Signed-off-by: David Lin <dtwlin@google.com>

msm_cci: fix inconsistent mutex_lock

drivers/media/platform/msm/camera_v2/sensor/cci/msm_cci.c:939
msm_cci_i2c_read() warn: inconsistent returns
'mutex:&cci_dev->cci_master_info[master].mutex_q[queue]'

Change-Id: Ied241d3ff2fd00d4ce892e250a6236fccf16fac9
Signed-off-by: David Lin <dtwlin@google.com>

msm: memshare: relaese mutex if req client id is not found

This fixes the smatch warning below:

drivers/soc/qcom/memshare/msm_memshare.c:570 handle_alloc_generic_req()
warn: inconsistent returns 'mutex:&memsh_drv->mem_share'.

Bug: 35898203
Change-Id: I86f3d77c9bb471b1bc26360e11e378fa3d1a3f66
Signed-off-by: David Lin <dtwlin@google.com>

thermal: qpnp-adc-tm: release lock upon disable_chan_meas failure

This fixes the smath warning below:

drivers/thermal/qpnp-adc-tm.c:2943 qpnp_adc_tm_disable_chan_meas() warn:
inconsistent returns 'mutex:&chip->adc->adc_lock'.

Bug: 35898203
Change-Id: I149ed4868cd4754246b3b8845a0af7f1f08c0931
Signed-off-by: David Lin <dtwlin@google.com>

qcom: qmi: release mutex upon qmi_svc_event_notifier_register error

This fixes the following smatch warning:

drivers/soc/qcom/qmi_interface.c:2019 qmi_svc_event_notifier_register()
warn: inconsistent returns 'mutex:&temp->svc_addr_list_lock'.

Change-Id: I2ada7d79a0ac6b6a14abad0cb463af491dd1c319
Signed-off-by: David Lin <dtwlin@google.com>

i2c-msm-v2: allow i2c_adapter to retry on arbitration lost

In case of error on lost arbitration, the host should at least attempt
to retry in case if the bus error is transient (i.e., from signal
interference or misbehaved devices). Use the default 2s timeout setting.

Bug: 35439882

Change-Id: Id9bd5a5ea764405401588220a2d2bf0fd85111f7
Signed-off-by: David Lin <dtwlin@google.com>

msm_rng: fix issue with unbalanced clk_put

This patch fixes the following coccicheck errors:

msm_rng.c:335:2-8: ERROR: missing clk_put;
clk_get on line 282 and execution via conditional on line 333
msm_rng.c:335:2-8: ERROR: missing clk_put;
clk_get on line 285 and execution via conditional on line 333

Bug: 35898203
Change-Id: Id6e0854ec11f95fe2bf7f887876535e2d8e74d22
Signed-off-by: David Lin <dtwlin@google.com>

power: reset: allow device to preserve memory on restart

* Always perform a soft reset as this preserves memory contents,
  including pstore and other persistent memory.

Change-Id: Ideca44c9f38d2ebcd437ff289f8e036922eafcd2

Revert "qcacld-3.0: Fix OOB in wma_stats_event_handler"

* This change makes WiFi report invalid signal strength.

This reverts commit be468730d315e973e9936da275b06600d0ce276c.

Change-Id: I01094049520ea706c27e00f316539f9d9d53bbc7

staging: qcacld-3.0: make debug functions configurable

Change-Id: If0643fc66aac1846fc5e1466d047ff31a5b175c3

staging: qcacld-3.0: Enable WLAN_WARN_ON_ASSERT for debug builds

QDF_ASSERT is being featurized in
I39e3ab6499210569b6ce09d77ee72f0081741989. Enable the QDF_ASSERT feature
in debug builds by default.

Change-Id: I96484e6dbebcecf17ae7877dc30906ed8fa90bd7
CRs-Fixed: 2211987

staging: qca-wifi-host-cmn: Featurize QDF_ASSERT

QDF_ASSERT is not properly featurized with its own build time config
flag. This leads to unnecessary logs and increased driver size for
platforms which do not want the feature enabled. Use the newly
introduced WLAN_WARN_ON_ASSERT build time flag to decide if QDF_ASSERT
should be a no-op.

Change-Id: I39e3ab6499210569b6ce09d77ee72f0081741989
CRs-Fixed: 2211983

staging: qca-wifi-host-cmn: fix build after disabling debug

../drivers/staging/qcacld-3.0/../qca-wifi-host-cmn/qdf/linux/src/qdf_event.c:363:54: error: expected expression
                        "Failed to add event in the list in %s", __func__),
                                                                          ^
1 error generated.

Change-Id: I0412209ffdbbeabb87a289b96e47f9785f18d23c
Signed-off-by: Akhil Narang <akhilnarang.1999@gmail.com>

staging: qcacld-3.0: fix build after disabling debug

../drivers/staging/qcacld-3.0/core/hdd/src/wlan_hdd_tx_rx.c:1569:45: error: expected expression
                hdd_debug("LRO and GRO both are disabled");
                                                          ^
1 error generated.

Convert to a normal if-else statement

Change-Id: Ia210044d6d6103a1120f0e5fdb74b88ff28d8fc8
Signed-off-by: Akhil Narang <akhilnarang.1999@gmail.com>

staging: qcacld-3.0: disable debug build

Change-Id: I13bc8b229f6bc3b5e2264188765c5af1cfe43ab9

staging: qcacld-3.0: fix non-debug build

Change-Id: Ifa75acbdd3f5a316fcb593635585b74150833179

staging: qcacld-3.0: load driver at device_initcall

The earlier, the better.

Change-Id: Iae43260050117d7b464dd3c7f47bf8093941a274
Signed-off-by: Sultanxda <sultanxda@gmail.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>

staging: qcacld-3.0: load driver on late initcall when not built as a module

Requiring userspace to write to /sys/kernel/boot_wlan/boot_wlan to boot
up the wlan device is unnecessary and blocks userspace for the large
amount of time it takes for wlan boot to finish.

Instead, load the driver asynchronously on late_initcall.

Change-Id: I4d696b9d46de032158fd223c60d9a7dbde26cc3f
Signed-off-by: Sultanxda <sultanxda@gmail.com>
[nc: Fix unused variable function warning]
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>

staging: qcacld-3.0: add sme_power_save_api.h include

Change-Id: Ic5c408a59ea0f859393fbc6e3f6ba6f0c391df43