A xHC USB 3 port might miss the first wake signal from a USB 3 device
if the port LFPS reveiver isn't enabled fast enough after xHC resume.
xHC host will anyway be resumed by a PME# signal, but will go back to
suspend if no port activity is seen.
The device resends the U3 LFPS wake signal after a 100ms delay, but
by then host is already suspended, starting all over from the
beginning of this issue.
USB 3 specs say U3 wake LFPS signal is sent for max 10ms, then device
needs to delay 100ms before resending the wake.
Don't suspend immediately if port activity isn't detected in resume.
Instead add a retry. If there is no port activity then delay for 120ms,
and re-check for port activity.
Cc: <stable@vger.kernel.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20210311115353.2137560-3-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 253f588c70)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I30e4e5f6859e4e4605a32c03a1090ccb5222ae0e
On some systems rt2800usb and mt7601u devices are unable to operate since
commit f8f80be501 ("xhci: Use soft retry to recover faster from
transaction errors")
Seems that some xHCI controllers can not perform Soft Retry correctly,
affecting those devices.
To avoid the problem add xhci->quirks flag that restore pre soft retry
xhci behaviour for affected xHCI controllers. Currently those are
AMD_PROMONTORYA_4 and AMD_PROMONTORYA_2, since it was confirmed
by the users: on those xHCI hosts issue happen and is gone after
disabling Soft Retry.
[minor commit message rewording for checkpatch -Mathias]
Fixes: f8f80be501 ("xhci: Use soft retry to recover faster from transaction errors")
Cc: <stable@vger.kernel.org> # 4.20+
Reported-by: Bernhard <bernhard.gebetsberger@gmx.at>
Tested-by: Bernhard <bernhard.gebetsberger@gmx.at>
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202541
Link: https://lore.kernel.org/r/20210311115353.2137560-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit a4a251f8c2)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ie909d0e08b51795ad3db0975881157a04aafc8a7
This commit adds a trace event which allows tracing the beginnings of RCU
CPU stall warnings on systems where sysctl_panic_on_rcu_stall is disabled.
The first parameter is the name of RCU flavor like other trace events.
The second parameter indicates whether this is a stall of an expedited
grace period, a self-detected stall of a normal grace period, or a stall
of a normal grace period detected by some CPU other than the one that
is stalled.
RCU CPU stall warnings are often caused by external-to-RCU issues,
for example, in interrupt handling or task scheduling. Therefore,
this event uses TRACE_EVENT, not TRACE_EVENT_RCU, to avoid requiring
those interested in tracing RCU CPU stalls to rebuild their kernels
with CONFIG_RCU_TRACE=y.
Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
Reviewed-by: Neeraj Upadhyay <neeraju@codeaurora.org>
Signed-off-by: Sangmoon Kim <sangmoon.kim@samsung.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
(cherry picked from commit 71580d6503f747f1b06ef8dbb7cdbbe20400a2ec
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev)
Bug: 177483057
Change-Id: Ie2f0340725a2fb582d026ecfaf5e1d35cc90fece
Signed-off-by: Sangmoon Kim <sangmoon.kim@samsung.com>
Export the following xhci symbols which will allow vendor modules
to perform their own ring management. These will be used to create
and manage additional secondary rings that are used to offload to a
separate coprocessor which interacts with the xHC controller.
xhci_ring_alloc
- Allocate a struct xhci_ring.
xhci_alloc_erst
xhci_free_erst
- Allocate and free event ring segment tables.
xhci_trb_virt_to_dma
- Used to retrieve the DMA address of a TRB
xhci_ring_cmd_db
- Notify the controller when a new command is issued
xhci_alloc_command
xhci_free_command
- Allocate and free a struct xhci_command
xhci_queue_stop_endpoint
- Issue a stop endpoint command to the controller
Bug: 182336717
Change-Id: I9d4c5884108e656e890aca8137d4ef580bcd7a12
Signed-off-by: Jack Pham <jackp@codeaurora.org>
The DWC3 runtime suspend routine checks for the USB connected parameter to
determine if the controller can enter into a low power state. The
connected state is only set to false after receiving a disconnect event.
However, in the case of a device initiated disconnect (i.e. UDC unbind),
the controller is halted and a disconnect event is never generated. Set
the connected flag to false if issuing a device initiated disconnect to
allow the controller to be suspended.
Signed-off-by: Wesley Cheng <wcheng@codeaurora.org>
Link: https://lore.kernel.org/r/1609283136-22140-2-git-send-email-wcheng@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 177879761
(cherry picked from commit 77adb8bdf4)
Change-Id: Ida95a1274f186cf81d40489ae0bdf2c702779a7c
Signed-off-by: Ray Chi <raychi@google.com>
This patch effectively reverts 2df99b6397 ("ANDROID: KVM: arm64: disable
CFI for hypervisor code") now that the arm64 KVM hypervisor code builds
correctly with LTO enabled, which is also the case upstream. CFI remains
disabled, but only for the nVHE hyp object at EL2.
Cc: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 145210207
Change-Id: I5084f880576dd6a23b8e15eec840f666f36bd2b1
It recently became apparent that the ARMv8 architecture has interesting
rules regarding attributes being used when fetching instructions
if the MMU is off at Stage-1.
In this situation, the CPU is allowed to fetch from the PoC and
allocate into the I-cache (unless the memory is mapped with
the XN attribute at Stage-2).
If we transpose this to vcpus sharing a single physical CPU,
it is possible for a vcpu running with its MMU off to influence
another vcpu running with its MMU on, as the latter is expected to
fetch from the PoU (and self-patching code doesn't flush below that
level).
In order to solve this, reuse the vcpu-private TLB invalidation
code to apply the same policy to the I-cache, nuking it every time
the vcpu runs on a physical CPU that ran another vcpu of the same
VM in the past.
This involve renaming __kvm_tlb_flush_local_vmid() to
__kvm_flush_cpu_context(), and inserting a local i-cache invalidation
there.
Cc: stable@vger.kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
Acked-by: Will Deacon <will@kernel.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20210303164505.68492-1-maz@kernel.org
(cherry picked from commit 01dc9262ff
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git fixes)
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 178098380
Test: atest VirtualizationHostTestCases on an EL2-enabled device
Change-Id: I05b5c2065f522225c744264caa781951d8b7888c
allmodconfig + CONFIG_LTO_CLANG_THIN=y fails to build due to following
linker errors:
ld.lld: error: irqbypass.c:(function __guest_enter: .text+0x21CC):
relocation R_AARCH64_CONDBR19 out of range: 2031220 is not in
[-1048576, 1048575]; references hyp_panic
>>> defined in vmlinux.o
ld.lld: error: irqbypass.c:(function __guest_enter: .text+0x21E0):
relocation R_AARCH64_ADR_PREL_LO21 out of range: 2031200 is not in
[-1048576, 1048575]; references hyp_panic
>>> defined in vmlinux.o
This is because with LTO, the compiler ends up placing hyp_panic()
more than 1MB away from __guest_enter(). Use an unconditional branch
and adr_l instead to fix the issue.
Link: https://github.com/ClangBuiltLinux/linux/issues/1317
Reported-by: Nathan Chancellor <nathan@kernel.org>
Suggested-by: Marc Zyngier <maz@kernel.org>
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Acked-by: Will Deacon <will@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210305202124.3768527-1-samitolvanen@google.com
(cherry picked from commit dbaee836d6
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git fixes)
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 178098380
Test: atest VirtualizationHostTestCases on an EL2-enabled device
Change-Id: I1c567b1aa44fc96ac044d572248bf1b4b4e13a68
When walking the page tables at a given level, and if the start
address for the range isn't aligned for that level, we propagate
the misalignment on each iteration at that level.
This results in the walker ignoring a number of entries (depending
on the original misalignment) on each subsequent iteration.
Properly aligning the address before the next iteration addresses
this issue.
Cc: stable@vger.kernel.org
Reported-by: Howard Zhang <Howard.Zhang@arm.com>
Acked-by: Will Deacon <will@kernel.org>
Signed-off-by: Jia He <justin.he@arm.com>
Fixes: b1e57de62c ("KVM: arm64: Add stand-alone page-table walker infrastructure")
[maz: rewrite commit message]
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210303024225.2591-1-justin.he@arm.com
(cherry picked from commit e85583b3f1fe62c9b371a3100c1c91af94005ca9
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git fixes)
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 178098380
Test: atest VirtualizationHostTestCases on an EL2-enabled device
Change-Id: Ic5d8a5966201610ead899eacf1d75b94df572be8
Add and export get_each_dmabuf function which helps in
traversing the db_list, this will be used by the minidump
module to get dmabuf info.
Bug: 181203151
Change-Id: Ie24788fcf9cf0a49316cb871dcb9191e8084ccde
Signed-off-by: Vijayanand Jitta <vjitta@codeaurora.org>
There is a possible chance that some cooling device stats buffer
allocation fails due to very high cooling device max state value.
Later cooling device update sysfs can try to access stats data
for the same cooling device. It will lead to NULL pointer
dereference issue.
Add a NULL pointer check before accessing thermal cooling device
stats data. It fixes the following bug
[ 26.812833] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004
[ 27.122960] Call trace:
[ 27.122963] do_raw_spin_lock+0x18/0xe8
[ 27.122966] _raw_spin_lock+0x24/0x30
[ 27.128157] thermal_cooling_device_stats_update+0x24/0x98
[ 27.128162] cur_state_store+0x88/0xb8
[ 27.128166] dev_attr_store+0x40/0x58
[ 27.128169] sysfs_kf_write+0x50/0x68
[ 27.133358] kernfs_fop_write+0x12c/0x1c8
[ 27.133362] __vfs_write+0x54/0x160
[ 27.152297] vfs_write+0xcc/0x188
[ 27.157132] ksys_write+0x78/0x108
[ 27.162050] ksys_write+0xf8/0x108
[ 27.166968] __arm_smccc_hvc+0x158/0x4b0
[ 27.166973] __arm_smccc_hvc+0x9c/0x4b0
[ 27.186005] el0_svc+0x8/0xc
Link: https://lore.kernel.org/linux-pm/7486c27b-c6fb-4686-811c-85945ec5a273@linaro.org/T/#m0ea0afc9eb655a66d5352520a650b4525141a041
Bug: 182193227
Change-Id: I67831afb887d4c97f9cdf3274024f5d38ea2c22d
Signed-off-by: Manaf Meethalavalappu Pallikunhi <manafm@codeaurora.org>
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
The product config for GKI should be as optimized as possible, and
"full" LTO can result in additional optimizations that are not possible
with "thin" LTO.
Bug: 167259389
Signed-off-by: Alistair Delva <adelva@google.com>
Change-Id: I3a3f2e0069a77f501d0b4cffc35d9c813735d210
This helps in reducing the static memory usage of stack
depot when CONFIG_PAGE_OWNER is set.
Bug: 171354330
Change-Id: I7dceceacef5610bde53877f57bbbd72366ff61b4
Signed-off-by: Vijayanand Jitta <vjitta@codeaurora.org>
move hook to collect scheduling information and apply vendor's
tuning before task's scheduling priority is changed
Bug: 163431711
Signed-off-by: Frankie Chang <frankie.chang@mediatek.com>
Change-Id: I61a7ab663316c0fbcb28d1b6e523649a6374b492
(cherry picked from commit 5cf5bc7523bd5608590de487de896c1026161a18)
Add __cfi_slowpath to android/abi_gki_aarch64_qcom since CFI was enabled
in gki_defconfig.
Bug: 182137499
Change-Id: Ic67fb6fcdf652fbcc94a19ef3334dc0df01d19ec
Signed-off-by: Elliot Berman <eberman@codeaurora.org>
While interpreting CC_STATUS, ROLE_CONTROL has to be read to make
sure that CC1/CC2 is not forced presenting Rp/Rd.
>From the TCPCI spec:
4.4.5.2 ROLE_CONTROL (Normative):
The TCPM shall write B6 (DRP) = 0b and B3..0 (CC1/CC2) if it wishes
to control the Rp/Rd directly instead of having the TCPC perform
DRP toggling autonomously. When controlling Rp/Rd directly, the
TCPM writes to B3..0 (CC1/CC2) each time it wishes to change the
CC1/CC2 values. This control is used for TCPM-TCPC implementing
Source or Sink only as well as when a connection has been detected
via DRP toggling but the TCPM wishes to attempt Try.Src or Try.Snk.
Table 4-22. CC_STATUS Register Definition:
If (ROLE_CONTROL.CC1 = Rd) or ConnectResult=1)
00b: SNK.Open (Below maximum vRa)
01b: SNK.Default (Above minimum vRd-Connect)
10b: SNK.Power1.5 (Above minimum vRd-Connect) Detects Rp-1.5A
11b: SNK.Power3.0 (Above minimum vRd-Connect) Detects Rp-3.0A
If (ROLE_CONTROL.CC2=Rd) or (ConnectResult=1)
00b: SNK.Open (Below maximum vRa)
01b: SNK.Default (Above minimum vRd-Connect)
10b: SNK.Power1.5 (Above minimum vRd-Connect) Detects Rp 1.5A
11b: SNK.Power3.0 (Above minimum vRd-Connect) Detects Rp 3.0A
Fixes: 74e656d6b0 ("staging: typec: Type-C Port Controller Interface driver (tcpci)")
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Link: https://lore.kernel.org/r/20210304070931.1947316-1-badhri@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 175d5cd62631dedbaee68ec88f1103cbac679518
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Id4da23c64cfda464ddcbf6aa8d0fd678cc1a3914
Add the calc_index vendor hook symbol which is needed for
vendor modules.
Bug: 182018614
Signed-off-by: Huang Yiwei <hyiwei@codeaurora.org>
Change-Id: Id15183b0423dd2ee4baf72234f425904e29494f9
Add a vendor hook after attaching a task to a cgroup to
recognize the group_id for performance tuning
Bug: 181917687
Signed-off-by: Frankie Chang <frankie.chang@mediatek.com>
Change-Id: I603afa3d893dd575a7dcb97f83bd9eacb8315bab
(cherry picked from commit de089a37a3d248608a1d5855a4ae82ebad3ec2ab)
In USB2 Spec:
"11.18.5 TT Response Generation
In general, there will be two (or more) complete-split
transactions scheduled for a periodic endpoint.
However, for interrupt endpoints, the maximum size of
the full-/low-speed transaction guarantees that it can
never require more than two complete-split transactions.
Two complete-split transactions are only required
when the transaction spans a microframe boundary."
Due to the maxp is 64, and less then 188 (at most in one
microframe), seems never span boundary, so use only one CS
for FS/LS interrupt transfer, this will save some bandwidth.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Link: https://lore.kernel.org/r/5b9ff09f53d23cf9e5c5437db4ffc18b798bf60c.1615170625.git.chunfeng.yun@mediatek.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit fe2ee2b69416f3696b0b0f1eafe6b869cc0448bf
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I5670c8ac20acb974204deba8db82658de9876a61
