-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
APOLLO backports until V6.0 #2
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* seperate device-specific configs
* Faster Compiling
* Its very annoying Signed-off-by: Anan Jaser <ananjaser@gmail.com>
Userspace parses this and sets the ro.boot.verifiedbootstate prop according to the value that this flag has. When ro.boot.verifiedbootstate is not 'green', SafetyNet is tripped and fails the CTS test. Hide verifiedbootstate from /proc/cmdline in order to fix the failed SafetyNet CTS check.
SafetyNet checks androidboot.veritymode in Nougat, so remove it. Additionally, remove androidboot.enable_dm_verity and androidboot.secboot in case SafetyNet will check them in the future. Signed-off-by: Sultanxda <sultanxda@gmail.com>
boeffla_wl_blocker: add generic wakelock blocker driver v1.0.0 Based on ideas of FranciscoFranco's non-generic driver. Sysfs node: /sys/class/misc/boeffla_wakelock_blocker/wakelock_blocker - list of wakelocks to be blocked, separated by semicolons /sys/class/misc/boeffla_wakelock_blocker/debug - write: 0/1 to switch off and on debug logging into dmesg - read: get current driver internals /sys/class/misc/boeffla_wakelock_blocker/version - show driver version Signed-off-by: andip71 <andreasp@gmx.de> boeffla_wl_blocker: update to wakelock blocker driver v1.0.1 - currently active wakelocks on the list are forcefully killed Signed-off-by: andip71 <andreasp@gmx.de> boeffla_wl_blocker: update to wakelock blocker driver v1.1.0 There are now two lists: - the previously existing list of user defined wakelocks to block - a new list called wakelock_blocker_default which comes prepopulated with the most common and safe wakelocks to block: qcom_rx_wakelock;wlan;wlan_wow_wl;wlan_extscan_wl;netmgr_wl;NETLINK A combination of both wakelock lists will be blocked finally. Signed-off-by: andip71 <andreasp@gmx.de> boeffla_wl_blocker: increased string length limit boeffla_wl_blocker: deleted default wakelocks Signed-off-by: morogoku <morogoku@hotmail.com> wl_blocker: create basic wakelock list, cronos_8890
Samsung sets QoS latency to zero, which disables all CPU idle functions on input, causing high power usage, specially when Exynos 9810's M3 cores power usage isn't friendly at all To avoid touch latency, we'll adapt another method that significantly improves IRQ behaviours Signed-off-by: Diep Quynh <remilia.1505@gmail.com>
Currently, CPU can enter deep sleep while waiting for data on the i2c bug. That means an i2c read of 8 bytes can take as long as 10 ms, which would overrun the desired interrupt handling time. Use pm qos to require low latency and prevent CPU from entering deep sleep while handling touch interrupts. Bug: 110939384 Test: look at the i2c read traces: 1) ./external/chromium-trace/systrace.py --atrace-categories=view,wm,am,app,gfx,i2c,sched,irq,video,power,input,workq,freq 2) perform a fling 3) review the i2c read duration on the touchscreen bus Change-Id: Icf8ab09324003a85af70517769ced3bae52f705c Signed-Off-By: Siarhei Vishniakou <svv@google.com>
This is a workaround for gaming scenairo when big cluster thermal went over the roof, and will not interfere most latency sensitive user workloads like web browsing Signed-off-by: Diep Quynh <remilia.1505@gmail.com>
* Adapted from Exynos8895 to avoid issues with no-fade
Other drivers like the mtp driver use a proper 'function.name' to make the configfs work. So lets correct mass storages name which will allow drivedroid to work.
Signed-off-by: corsicanu <corsicanu22@gmail.com>
commit 000ade8016400d93b4d7c89970d96b8c14773d45 upstream. By passing a limit of 2 bytes to strncat, strncat is limited to writing fewer bytes than what it's supposed to append to the name here. Since the bounds are checked on the line above this, just remove the string bounds checks entirely since they're unneeded. Signed-off-by: Sultan Alsawaf <sultanxda@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: corsicanu <corsicanu22@gmail.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This reverts commit 159d3d461d95d3a4af99c6188b24aaefc2078129.
* Seems that Android 13 100~130 is needed and 60 in android 12
* from M625F * Throttling for KSWAPD
* Needed for APatch * Also enable usb serial
This reverts commit cce749a06972ffc07cab7044addb7d7a14daf48c.
* remove unused process freezer
* Newer versions seem to have different logic for handling newer android versions
* Port latest version from exynos9820
* adds LOOP_SET_BLOCK_SIZE IOCTL
This reverts commit 9ee40d3.
This reverts commit 8f1b1c1.
This reverts commit 7a43eac.
This reverts commit cd630bc.
This reverts commit 04a4ab3.
* Fixes compilation error
duhansysl
pushed a commit
that referenced
this pull request
Sep 30, 2024
LLVM's integrated assembler appears to assume an argument with default value is passed whenever it sees a comma right after the macro name. It will be fine if the number of following arguments is one less than the number of parameters specified in the macro definition. Otherwise, it fails. For example, the following code works: $ cat foo.s .macro foo arg1=2, arg2=4 ldr r0, [r1, #\arg1] ldr r0, [r1, #\arg2] .endm foo, arg2=8 $ llvm-mc -triple=armv7a -filetype=obj foo.s -o ias.o arm-linux-gnueabihf-objdump -dr ias.o ias.o: file format elf32-littlearm Disassembly of section .text: 00000000 <.text>: 0: e5910001 ldr r0, [r1, #2] 4: e5910003 ldr r0, [r1, #8] While the the following code would fail: $ cat foo.s .macro foo arg1=2, arg2=4 ldr r0, [r1, #\arg1] ldr r0, [r1, #\arg2] .endm foo, arg1=2, arg2=8 $ llvm-mc -triple=armv7a -filetype=obj foo.s -o ias.o foo.s:6:14: error: too many positional arguments foo, arg1=2, arg2=8 This causes build failures as follows: arch/arm64/kernel/vdso/gettimeofday.S:230:24: error: too many positional arguments clock_gettime_return, shift=1 ^ arch/arm64/kernel/vdso/gettimeofday.S:253:24: error: too many positional arguments clock_gettime_return, shift=1 ^ arch/arm64/kernel/vdso/gettimeofday.S:274:24: error: too many positional arguments clock_gettime_return, shift=1 This error is not in mainline because commit 28b1a824a4f4 ("arm64: vdso: Substitute gettimeofday() with C implementation") rewrote this assembler file in C as part of a 25 patch series that is unsuitable for stable. Just remove the comma in the clock_gettime_return invocations in 4.19 so that GNU as and LLVM's integrated assembler work the same. Link: ClangBuiltLinux/linux#1349 Suggested-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Jian Cai <jiancai@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Change-Id: If006e175105cf7387be43fe1ed53d0563d10be54
duhansysl
pushed a commit
that referenced
this pull request
Sep 30, 2024
LLVM's integrated assembler appears to assume an argument with default value is passed whenever it sees a comma right after the macro name. It will be fine if the number of following arguments is one less than the number of parameters specified in the macro definition. Otherwise, it fails. For example, the following code works: $ cat foo.s .macro foo arg1=2, arg2=4 ldr r0, [r1, #\arg1] ldr r0, [r1, #\arg2] .endm foo, arg2=8 $ llvm-mc -triple=armv7a -filetype=obj foo.s -o ias.o arm-linux-gnueabihf-objdump -dr ias.o ias.o: file format elf32-littlearm Disassembly of section .text: 00000000 <.text>: 0: e5910001 ldr r0, [r1, #2] 4: e5910003 ldr r0, [r1, #8] While the the following code would fail: $ cat foo.s .macro foo arg1=2, arg2=4 ldr r0, [r1, #\arg1] ldr r0, [r1, #\arg2] .endm foo, arg1=2, arg2=8 $ llvm-mc -triple=armv7a -filetype=obj foo.s -o ias.o foo.s:6:14: error: too many positional arguments foo, arg1=2, arg2=8 This causes build failures as follows: arch/arm64/kernel/vdso/gettimeofday.S:230:24: error: too many positional arguments clock_gettime_return, shift=1 ^ arch/arm64/kernel/vdso/gettimeofday.S:253:24: error: too many positional arguments clock_gettime_return, shift=1 ^ arch/arm64/kernel/vdso/gettimeofday.S:274:24: error: too many positional arguments clock_gettime_return, shift=1 This error is not in mainline because commit 28b1a824a4f4 ("arm64: vdso: Substitute gettimeofday() with C implementation") rewrote this assembler file in C as part of a 25 patch series that is unsuitable for stable. Just remove the comma in the clock_gettime_return invocations in 4.19 so that GNU as and LLVM's integrated assembler work the same. Link: ClangBuiltLinux/linux#1349 Suggested-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Jian Cai <jiancai@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Change-Id: If006e175105cf7387be43fe1ed53d0563d10be54
duhansysl
pushed a commit
that referenced
this pull request
Oct 1, 2024
LLVM's integrated assembler appears to assume an argument with default value is passed whenever it sees a comma right after the macro name. It will be fine if the number of following arguments is one less than the number of parameters specified in the macro definition. Otherwise, it fails. For example, the following code works: $ cat foo.s .macro foo arg1=2, arg2=4 ldr r0, [r1, #\arg1] ldr r0, [r1, #\arg2] .endm foo, arg2=8 $ llvm-mc -triple=armv7a -filetype=obj foo.s -o ias.o arm-linux-gnueabihf-objdump -dr ias.o ias.o: file format elf32-littlearm Disassembly of section .text: 00000000 <.text>: 0: e5910001 ldr r0, [r1, #2] 4: e5910003 ldr r0, [r1, #8] While the the following code would fail: $ cat foo.s .macro foo arg1=2, arg2=4 ldr r0, [r1, #\arg1] ldr r0, [r1, #\arg2] .endm foo, arg1=2, arg2=8 $ llvm-mc -triple=armv7a -filetype=obj foo.s -o ias.o foo.s:6:14: error: too many positional arguments foo, arg1=2, arg2=8 This causes build failures as follows: arch/arm64/kernel/vdso/gettimeofday.S:230:24: error: too many positional arguments clock_gettime_return, shift=1 ^ arch/arm64/kernel/vdso/gettimeofday.S:253:24: error: too many positional arguments clock_gettime_return, shift=1 ^ arch/arm64/kernel/vdso/gettimeofday.S:274:24: error: too many positional arguments clock_gettime_return, shift=1 This error is not in mainline because commit 28b1a824a4f4 ("arm64: vdso: Substitute gettimeofday() with C implementation") rewrote this assembler file in C as part of a 25 patch series that is unsuitable for stable. Just remove the comma in the clock_gettime_return invocations in 4.19 so that GNU as and LLVM's integrated assembler work the same. Link: ClangBuiltLinux/linux#1349 Suggested-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Jian Cai <jiancai@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Change-Id: If006e175105cf7387be43fe1ed53d0563d10be54
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.