Commit graph

608886 commits

Author SHA1 Message Date
Mark Salyzyn
d88f1e0d41 FROMLIST: [PATCH v5 01/12] arm: vdso: rename vdso_datapage variables
(cherry picked from url https://patchwork.kernel.org/patch/10044505/)

Take an effort to recode the arm64 vdso code from assembler to C
previously submitted by Andrew Pinski <apinski@cavium.com>, rework
it for use in both arm and arm64, overlapping any optimizations
for each architecture. But instead of landing it in arm64, land the
result into lib/vdso and unify both implementations to simplify
future maintenance.

Rename seq_count to tb_seq_count. Rename tk_is_cntvct to use_syscall.
Rename cs_mult to cs_mono_mult. All to align with the variables in the
arm64 vdso datapage. Rework vdso_read_begin() and vdso_read_retry()
functions to reflect modern access patterns for tb_seq_count field.

Update copyright message to reflect the start of the contributions in
this series.

Signed-off-by: Mark Salyzyn <salyzyn@android.com>
Cc: James Morse <james.morse@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dmitry Safonov <dsafonov@virtuozzo.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Laura Abbott <labbott@redhat.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Andy Gross <andy.gross@linaro.org>
Cc: Kevin Brodsky <kevin.brodsky@arm.com>
Cc: Andrew Pinski <apinski@cavium.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Bug: 63737556
Bug: 20045882
Change-Id: I13f16e71b1ecba3d72b999caafef72e3c7f48dfe
2020-11-03 21:30:41 +01:00
Kevin Brodsky
15be945102 FROMLIST: [PATCH v2 3/3] arm64: compat: Add CONFIG_KUSER_HELPERS
(cherry picked from url http://lkml.iu.edu/hypermail/linux/kernel/1709.1/01903.html)

Make it possible to disable the kuser helpers by adding a KUSER_HELPERS
config option (enabled by default). When disabled, all kuser
helpers-related code is removed from the kernel and no mapping is done
at the fixed high address (0xffff0000); any attempt to use a kuser
helper from a 32-bit process will result in a segfault.

Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
Signed-off-by: Mark Salyzyn <salyzyn@android.com>
Bug: 9674955
Bug: 63737556
Bug: 20045882
Change-Id: Ie8c543301d39bfe88ef71fb6a669e571914b117b
2020-11-03 21:30:40 +01:00
Kevin Brodsky
5458cba42d FROMLIST: [PATCH v2 2/3] arm64: compat: Split the sigreturn trampolines and kuser helpers (assembler sources)
(cherry picked from url http://lkml.iu.edu/hypermail/linux/kernel/1709.1/01902.html)

AArch32 processes are currently installed a special [vectors] page that
contains the sigreturn trampolines and the kuser helpers, at the fixed
address mandated by the kuser helpers ABI.

Having both functionalities in the same page has become problematic,
because:

* It makes it impossible to disable the kuser helpers (the sigreturn
  trampolines cannot be removed), which is possible on arm.

* A future 32-bit vDSO would provide the sigreturn trampolines itself,
  making those in [vectors] redundant.

This patch addresses the problem by moving the sigreturn trampolines
sources to its own file.  Wrapped the comments to reduce the wrath of
checkpatch.pl.

Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
Signed-off-by: Mark Salyzyn <salyzyn@android.com>
Bug: 9674955
Bug: 63737556
Bug: 20045882
Change-Id: I1d7b96e7cfbe979ecf4cb4996befd1f3ae0e64fd
2020-11-03 21:30:40 +01:00
Kevin Brodsky
cf2d3b54d3 FROMLIST: [PATCH v2 1/3] arm64: compat: Split the sigreturn trampolines and kuser helpers (C sources)
(cherry picked from url http://lkml.iu.edu/hypermail/linux/kernel/1709.1/01901.html)

AArch32 processes are currently installed a special [vectors] page that
contains the sigreturn trampolines and the kuser helpers, at the fixed
address mandated by the kuser helpers ABI.

Having both functionalities in the same page has become problematic,
because:

* It makes it impossible to disable the kuser helpers (the sigreturn
  trampolines cannot be removed), which is possible on arm.

* A future 32-bit vDSO would provide the sigreturn trampolines itself,
  making those in [vectors] redundant.

This patch addresses the problem by moving the sigreturn trampolines to
a separate [sigpage] page, mirroring [sigpage] on arm.

Even though [vectors] has always been a misnomer on arm64/compat, as
there is no AArch32 vector there (and now only the kuser helpers),
its name has been left unchanged, for compatibility with arm (there
are reports of software relying on [vectors] being there as the last
mapping in /proc/maps).

mm->context.vdso used to point to the [vectors] page, which is
unnecessary (as its address is fixed). It now points to the [sigpage]
page (whose address is randomized like a vDSO).

Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
Signed-off-by: Mark Salyzyn <salyzyn@android.com>
Bug: 9674955
Bug: 63737556
Bug: 20045882
Change-Id: I52a56ea71d7326df8c784f90eb73b5c324fe9d20
2020-11-03 21:30:40 +01:00
Chris Fries
fa65c420dd posix_cpu_timer: check return on cpu_timer_sample_group
If error, don't trust "now" time that it should be setting

kernel/time/posix-cpu-timers.c:1269:13: warning: 'now' may be used uninitialized in this function [-Wmaybe-uninitialized]

Change-Id: I679d99c335494bae50fd926663fad37aedb1487a
Signed-off-by: Chris Fries <cfries@google.com>
2020-11-03 21:30:40 +01:00
Park Ju Hyung
815e2d8190 msm_thermal: initialize later than arch drivers
If OSM driver is initialized later than msm_thermal, it will fail:

[    0.226183] cpu cpu0: dev_pm_opp_get_opp_count: OPP table not found (-19)
[    0.227931] msm_thermal:get_cpu_freq_plan_len Error reading CPU0 freq table len. error:-19
[    0.227955] cpu cpu4: dev_pm_opp_get_opp_count: OPP table not found (-19)
[    0.229631] msm_thermal:get_cpu_freq_plan_len Error reading CPU4 freq table len. error:-19
[    0.229652] cpu cpu0: dev_pm_opp_get_opp_count: OPP table not found (-19)
[    0.231380] msm_thermal:get_cpu_freq_plan_len Error reading CPU0 freq table len. error:-19
[    0.231404] cpu cpu4: dev_pm_opp_get_opp_count: OPP table not found (-19)
[    0.233095] msm_thermal:get_cpu_freq_plan_len Error reading CPU4 freq table len. error:-19

Change-Id: I98be9d37701f1f9366cef1427cfdd9082b8fb24c
Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com>
Signed-off-by: celtare21 <celtare21@gmail.com>
2020-11-03 21:30:39 +01:00
Wei Wang
8ebd4ae3ec dts: msm8998: disable hotplug in BCL mitigation
Bug: 63165849
Test: boot
Change-Id: Icc1131578be0a02542376d34e4f5cc7c53156bd9
Signed-off-by: Wei Wang <wvw@google.com>
Signed-off-by: joshuous <joshuous@gmail.com>
2020-11-03 21:30:39 +01:00
Daniel Vetter
311a604bcd net/sch_generic: Shut up noise
We can't allow spam in CI.

Upate 26th June 2018: This is still an issue:

[  224.739686] ------------[ cut here ]------------
[  224.739712] WARNING: CPU: 3 PID: 2982 at net/sched/sch_generic.c:461 dev_watchdog+0x1fd/0x210
[  224.739714] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_pcm i915 asix usbnet mii mei_me mei prime_numbers i2c_hid pinctrl_sunrisepoint pinctrl_intel btusb btrtl btbcm btintel bluetooth ecdh_generic
[  224.739775] CPU: 3 PID: 2982 Comm: gem_exec_suspen Tainted: G     U  W         4.18.0-rc2-CI-Patchwork_9414+ #1
[  224.739777] Hardware name: Dell Inc. XPS 13 9350/, BIOS 1.4.12 11/30/2016
[  224.739780] RIP: 0010:dev_watchdog+0x1fd/0x210
[  224.739781] Code: 49 63 4c 24 f0 eb 92 4c 89 ef c6 05 21 46 ad 00 01 e8 77 ee fc ff 89 d9 48 89 c2 4c 89 ee 48 c7 c7 88 4c 14 82 e8 a3 fe 84 ff <0f> 0b eb be 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 c7 47
[  224.739866] RSP: 0018:ffff88027dd83e40 EFLAGS: 00010286
[  224.739869] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000102
[  224.739871] RDX: 0000000080000102 RSI: ffffffff820c8c6c RDI: 00000000ffffffff
[  224.739873] RBP: ffff8802644c1540 R08: 0000000071be9b33 R09: 0000000000000000
[  224.739874] R10: ffff88027dd83dc0 R11: 0000000000000000 R12: ffff8802644c1588
[  224.739876] R13: ffff8802644c1160 R14: 0000000000000001 R15: ffff88026a5dc728
[  224.739878] FS:  00007f18f4887980(0000) GS:ffff88027dd80000(0000) knlGS:0000000000000000
[  224.739880] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  224.739881] CR2: 00007f4c627ae548 CR3: 000000022ca1a002 CR4: 00000000003606e0
[  224.739883] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  224.739885] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  224.739886] Call Trace:
[  224.739888]  <IRQ>
[  224.739892]  ? qdisc_reset+0xe0/0xe0
[  224.739894]  ? qdisc_reset+0xe0/0xe0
[  224.739897]  call_timer_fn+0x93/0x360
[  224.739903]  expire_timers+0xc1/0x1d0
[  224.739908]  run_timer_softirq+0xc7/0x170
[  224.739916]  __do_softirq+0xd9/0x505
[  224.739923]  irq_exit+0xa9/0xc0
[  224.739926]  smp_apic_timer_interrupt+0x9c/0x2d0
[  224.739929]  apic_timer_interrupt+0xf/0x20
[  224.739931]  </IRQ>
[  224.739934] RIP: 0010:delay_tsc+0x2e/0xb0
[  224.739936] Code: 49 89 fc 55 53 bf 01 00 00 00 e8 6d 2c 78 ff e8 88 9d b6 ff 41 89 c5 0f ae e8 0f 31 48 c1 e2 20 48 09 c2 48 89 d5 eb 16 f3 90 <bf> 01 00 00 00 e8 48 2c 78 ff e8 63 9d b6 ff 44 39 e8 75 36 0f ae
[  224.740021] RSP: 0018:ffffc900002f7d48 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13
[  224.740024] RAX: 0000000080000000 RBX: 0000000649565ca9 RCX: 0000000000000001
[  224.740026] RDX: 0000000080000001 RSI: ffffffff820c8c6c RDI: 00000000ffffffff
[  224.740027] RBP: 00000006493ea9ce R08: 000000005e81e2ee R09: 0000000000000000
[  224.740029] R10: 0000000000000120 R11: 0000000000000000 R12: 00000000002ad8d6
[  224.740030] R13: 0000000000000003 R14: 0000000000000004 R15: ffff88025caf5408
[  224.740040]  ? delay_tsc+0x66/0xb0
[  224.740045]  hibernation_debug_sleep+0x1c/0x30
[  224.740048]  hibernation_snapshot+0x2c1/0x690
[  224.740053]  hibernate+0x142/0x2a4
[  224.740057]  state_store+0xd0/0xe0
[  224.740063]  kernfs_fop_write+0x104/0x190
[  224.740068]  __vfs_write+0x31/0x180
[  224.740072]  ? rcu_read_lock_sched_held+0x6f/0x80
[  224.740075]  ? rcu_sync_lockdep_assert+0x29/0x50
[  224.740078]  ? __sb_start_write+0x152/0x1f0
[  224.740080]  ? __sb_start_write+0x168/0x1f0
[  224.740084]  vfs_write+0xbd/0x1a0
[  224.740088]  ksys_write+0x50/0xc0
[  224.740094]  do_syscall_64+0x55/0x190
[  224.740097]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[  224.740099] RIP: 0033:0x7f18f400a281
[  224.740100] Code: c3 0f 1f 84 00 00 00 00 00 48 8b 05 59 8d 20 00 c3 0f 1f 84 00 00 00 00 00 8b 05 8a d1 20 00 85 c0 75 16 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 57 f3 c3 0f 1f 44 00 00 41 54 55 49 89 d4 53
[  224.740186] RSP: 002b:00007fffd1f4fec8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[  224.740189] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f18f400a281
[  224.740190] RDX: 0000000000000004 RSI: 00007f18f448069a RDI: 0000000000000006
[  224.740192] RBP: 00007fffd1f4fef0 R08: 0000000000000000 R09: 0000000000000000
[  224.740194] R10: 0000000000000000 R11: 0000000000000246 R12: 000055e795d03400
[  224.740195] R13: 00007fffd1f50500 R14: 0000000000000000 R15: 0000000000000000
[  224.740205] irq event stamp: 1582591
[  224.740207] hardirqs last  enabled at (1582590): [<ffffffff810f9f9c>] vprintk_emit+0x4bc/0x4d0
[  224.740210] hardirqs last disabled at (1582591): [<ffffffff81a0111c>] error_entry+0x7c/0x100
[  224.740212] softirqs last  enabled at (1582568): [<ffffffff81c0034f>] __do_softirq+0x34f/0x505
[  224.740215] softirqs last disabled at (1582571): [<ffffffff8108c959>] irq_exit+0xa9/0xc0
[  224.740218] WARNING: CPU: 3 PID: 2982 at net/sched/sch_generic.c:461 dev_watchdog+0x1fd/0x210
[  224.740219] ---[ end trace 6e41d690e611c338 ]---

Change-Id: Ie3cc947a719d91ae7c9b7d93513b1728aa603211
References: https://bugzilla.kernel.org/show_bug.cgi?id=196399
Acked-by: Martin Peres <martin.peres@linux.intel.com>
Cc: Martin Peres <martin.peres@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170718082110.12524-1-daniel.vetter@ffwll.ch
2020-11-03 21:30:39 +01:00
Wei Wang
ac8f8f75ce do not call trace_printk on non-debug build
trace_printk will cause trace_printk_init_buffers executed in kernel
start. Remove them from non-debug build.

Test: see nasty message gone in dmesg
Bug: 64215528
Change-Id: I82b8435a3cf36123608aae572c843db8ad86ac8a
Signed-off-by: Wei Wang <wvw@google.com>
2020-11-03 21:30:39 +01:00
Thierry Strudel
9b90e8fb82 remove calls to trace_printk
Removes boot warning:
trace_printk() being used. Allocating extra memory.

Change-Id: I3347379da302fc273e9b1d2787863cb244837ce8
Signed-off-by: Thierry Strudel <tstrudel@google.com>
2020-11-03 21:30:39 +01:00
Sultanxda
d239dc3a52 devfreq: Don't force compilation of userspace governor
Change-Id: I540ed4fe4bef8f059e577c59a839b27ddee78345
Signed-off-by: Sultanxda <sultanxda@gmail.com>
2020-11-03 21:30:38 +01:00
Jean Delvare
b72e7db967 cpuidle: Don't enable all governors by default
Since commit d6f346f2d2 (cpuidle: improve governor Kconfig options)
the best cpuidle governor is selected automatically. There is little
point in additionally selecting the other one as it will not be used,
so don't select both governors by default.

Being able to select more than one governor is still good for
developers booting with cpuidle_sysfs_switch, though.

This fixes the second half of kernel BZ #65531.

Change-Id: I8757624f6bdc2d418b12ffcad294d273b9aca26d
Link: https://bugzilla.kernel.org/show_bug.cgi?id=65531
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Harsh Shandilya <harsh@prjkt.io>
2020-11-03 21:30:38 +01:00
Wei Wang
c2403431f7 ANDROID: mm: add config for default readahead size
Change the VM_MAX_READAHED value from the default 128KB to a
configurable value. This will allow the readahead window to grow to a
maximum size bigger than 128KB, which greatly benefits to sequential
read throughput and thus boot performance.

Bug: 62413151
Test: boot walleye 100ms faster
Change-Id: Iad448cf1198056de46654dcb409466802b3b908d
Signed-off-by: Wei Wang <wvw@google.com>
2020-11-03 21:30:38 +01:00
Eric Biggers
4d8bcbb48b security: pfk: fix build when ecryptfs is disabled
To avoid compile errors and warnings when the pfk module is enabled
without ecryptfs, the ecryptfs stubs need to be static inline.

Bug: 34712722
Change-Id: I39d715fcac1ff2f7781230cc2d1da2a8d803e974
Signed-off-by: Eric Biggers <ebiggers@google.com>
2020-11-03 21:30:38 +01:00
Neeraj Soni
384480646f scsi: ufs: Increase crypto thread priority
Crypto work is used to program file keys into
the Crypto HW. Some times the thread is scheduled
but is not executed and is preempted oftenly by
block i/o kworker. This causes same requests to be
requeued  leading to timeout and cpu overload issues.

Change-Id: Icd9b5108018b85d60d72858c92673e1f2feddbd4
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
2020-11-03 21:30:38 +01:00
Jerry Zhang
3b4f0ff0e0 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>
2020-11-03 21:30:37 +01:00
Jerry Zhang
59d01673ea 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>
2020-11-03 21:30:37 +01:00
Jerry Zhang
53d85374b8 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>
2020-11-03 21:30:37 +01:00
Jerry Zhang
4b0f74a70e 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>
2020-11-03 21:30:37 +01:00
Baolin Wang
f634019867 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>
2020-11-03 21:30:37 +01:00
Petri Gynther
73729b05ee 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>
2020-11-03 21:30:36 +01:00
Tim Murray
b132a588b4 Revert "Revert "select: use freezable blocking call""
This reverts commit 59612d1879.

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>
2020-11-03 21:30:36 +01:00
Thierry Strudel
782f48975e 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 bdd405d2a5 ("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 596d789a21 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>
2020-11-03 21:30:36 +01:00
Badhri Jagan Sridharan
daa6b3cc4a 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>
2020-11-03 21:30:36 +01:00
Banajit Goswami
9aec9c9e10 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>
2020-11-03 21:30:36 +01:00
jonghyun26.kim
927bce4ae9 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>
2020-11-03 21:30:35 +01:00
Siqi Lin
91730df4a8 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>
2020-11-03 21:30:35 +01:00
Siqi Lin
efa8cfb253 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>
2020-11-03 21:30:35 +01:00
Bulbul Dabi
c89c88db03 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>
2020-11-03 21:30:35 +01:00
Philip Cuadra
fb6fbd329a 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
2020-11-03 21:30:35 +01:00
Philip Cuadra
5459b384f2 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>
2020-11-03 21:30:34 +01:00
Philip Cuadra
0e265e1562 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>
2020-11-03 21:30:34 +01:00
Philip Cuadra
126edd9141 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
2020-11-03 21:30:34 +01:00
Philip Cuadra
d98e5d2d5f 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>
2020-11-03 21:30:34 +01:00
Michael Bestas
88bda1d53c thermal: tsens: Disable tsens_poll_check for msm8998
Change-Id: I7f9c9f63fe2987c5b75773d87fde26e263c5ac71
2020-11-03 21:30:34 +01:00
Stephen Boyd
0745c42f8d 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>
2020-11-03 21:30:33 +01:00
Uladzislau 2 Rezki
510802be8f 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>
2020-11-03 21:30:33 +01:00
Jens Axboe
3e419e234e 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>
2020-11-03 21:30:33 +01:00
Ram Chandrasekar
e0a33f5957 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>
2020-11-03 21:30:33 +01:00
Ram Chandrasekar
0781014985 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.

Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
2020-11-03 21:30:33 +01:00
Tim Murray
cf92dd0ca9 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>
2020-11-03 21:30:32 +01:00
Park Ju Hyung
fccb6e80ab 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>
2020-11-03 21:30:32 +01:00
Greg Kroah-Hartman
a92a3ba12c 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>
2020-11-03 21:30:32 +01:00
Srinivas Ramana
dfce62a901 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>
2020-11-03 21:30:32 +01:00
Trevor Bunker
74725f6614 drivers: pinctrl: mask non-wakeup interrupts in suspend path
Bug: 30079159
Change-Id: If66a7ab642d28c7a42e0af337e388af4c1915677
2020-11-03 21:30:32 +01:00
Michael Bestas
cfcb62c9e5 slimbus: Add missing brackets in slim_change_existing_chans
Change-Id: I2f13656d0e8aa18213b54314f19fcd33a96751c4
2020-11-03 21:30:31 +01:00
Subhash Jadavani
e44e3d4cee 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>
2020-11-03 21:30:31 +01:00
Subhash Jadavani
33f0ce8ba8 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>
2020-11-03 21:30:31 +01:00
Sayali Lokhande
c5e11ae58d 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>
2020-11-03 21:30:31 +01:00
Essential kernel team
0172172434 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
2020-11-03 21:30:30 +01:00