[power supply]: Cherry pick patches for enabling gs101 power supply #2
Open
fallaciousreasoning wants to merge 14 commits into
Open
[power supply]: Cherry pick patches for enabling gs101 power supply #2fallaciousreasoning wants to merge 14 commits into
fallaciousreasoning wants to merge 14 commits into
Conversation
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
Bluejay is Google's code name for Pixel 6a. Similar to Pixel 6 (Oriole), this is also based around its Tensor gs101 SoC.
the downstream fts driver now attempts to probe the device
Fixes the touchscreen-related device-tree definitions for the gs101, based on the ones from the downstream kernel. The chip ID format was also changed in the header. In the downstream drivers, this is configured via the device-tree (st,dchip_id), but for gs101 all devices use the same firmware files, so this should not be an issue. The main trick to get this working reliably was fixing a race condition with the regulators in the initialization of the power regulators in the driver. Since the driver was accessing the regulators a bit too early, it was failing to get them on the first try, since they had not yet been initialized. However, the clean-up function failed to release the GPIOs, which meant that the driver could not retry the initialization, and failed. This was fixed by adding a small check on the clean-up function to release the GPIOs if needed.
Signed-off-by: Peter Griffin <gpeter@google.com> Signed-off-by: Ingo Reitz <9l@9lo.re>
Signed-off-by: Peter Griffin <gpeter@google.com>
Signed-off-by: Peter Griffin <gpeter@google.com>
The interface of the Maxim MAX77759 fuel gauge has a lot of common with the Maxim MAX1720x. A major difference is the lack of non-volatile memory slave address. No slave is available at address 0xb of the i2c bus, which is coherent with the following driver from google: line 5836 disables non-volatile memory for m5 gauge. Link: https://android.googlesource.com/kernel/google-modules/bms/+/1a68c36bef474573cc8629cc1d121eb6a81ab68c/max1720x_battery.c Other differences include the lack of V_BATT register to read the battery level. The voltage must instead be read from V_CELL, the lowest voltage of all cells. The mask to identify the chip is different. The computation of the charge must also be changed to take into account TASKPERIOD, which can add a factor 2 to the result. Add support for the MAX77759 by taking into account all of those differences based on chip type. Do not advertise temp probes using the non-volatile memory as those are not available. The regmap was proposed by André Draszik in Link: https://lore.kernel.org/all/d1bade77b5281c1de6b2ddcb4dbbd033e455a116.camel@linaro.org/ Signed-off-by: Thomas Antoine <t.antoine@uclouvain.be>
The Maxim MAX77759 is an IC used to manage the power supply of the battery and the USB-C. Based on drivers from google, it contains at least a PMIC, a fuel gauge, a TCPCI and a charger. Use max77759-fg compatible to avoid conflict with drivers for other functions. The Maxim MAX77759 has no non-volatile memory so it doesn't require an address and instead requires a value for the current sensing resistor. Keep shunt-resistor-micro-ohms optional for the MAX17201/MAX17205 as it is not be used at the moment but could be in the future. (e.g. as a default value to be used in case of nvmem failure) Signed-off-by: Thomas Antoine <t.antoine@uclouvain.be>
Enable the Maxim MAX1720x as it is used by the gs101-oriole (Google Pixel 6) board. Signed-off-by: Thomas Antoine <t.antoine@uclouvain.be> Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
Add the node for the Maxim MAX77759 fuel gauge as a slave of the i2c. The TODO is still applicable given there are other slaves on the bus (e.g. PCA9468, other MAX77759 functions and the MAX20339 OVP). Signed-off-by: Thomas Antoine <t.antoine@uclouvain.be>
Member
|
I thought these got upstreamed in 6.17/6.18? |
Author
|
I think the first patch in the series of 5 has been upstreamed. Looking at https://github.com/torvalds/linux these other four don't seem to be there (checked the 6.18 tag too). |
Author
|
Looks like this merged recently, but might not be in this fork? |
Member
Thats 7.1-rc1. Might upgrade soon-ish anyway. |
ninelore
pushed a commit
that referenced
this pull request
May 12, 2026
commit a355eef upstream. Currently, the initialization of loongarch_jump_ops does not contain an assignment to its .free field. This causes disasm_line__free() to fall through to ins_ops__delete() for LoongArch jump instructions. ins_ops__delete() will free ins_operands.source.raw and ins_operands.source.name, and these fields overlaps with ins_operands.jump.raw_comment and ins_operands.jump.raw_func_start. Since in loongarch_jump__parse(), these two fields are populated by strchr()-ing the same buffer, trying to free them will lead to undefined behavior. This invalid free usually leads to crashes: Process 1712902 (perf) of user 1000 dumped core. Stack trace of thread 1712902: #0 0x00007fffef155c58 n/a (libc.so.6 + 0x95c58) #1 0x00007fffef0f7a94 raise (libc.so.6 + 0x37a94) #2 0x00007fffef0dd6a8 abort (libc.so.6 + 0x1d6a8) #3 0x00007fffef145490 n/a (libc.so.6 + 0x85490) #4 0x00007fffef1646f4 n/a (libc.so.6 + 0xa46f4) #5 0x00007fffef164718 n/a (libc.so.6 + 0xa4718) #6 0x00005555583a6764 __zfree (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x106764) #7 0x000055555854fb70 disasm_line__free (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x2afb70) #8 0x000055555853d618 annotated_source__purge (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x29d618) #9 0x000055555852300c __hist_entry__tui_annotate (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x28300c) #10 0x0000555558526718 do_annotate (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x286718) #11 0x000055555852ed94 evsel__hists_browse (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x28ed94) #12 0x000055555831fdd0 cmd_report (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x7fdd0) #13 0x000055555839b644 handle_internal_command (/home/csmantle/dist/linux-arch/tools/perf/perf + 0xfb644) #14 0x00005555582fe6ac main (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x5e6ac) #15 0x00007fffef0ddd90 n/a (libc.so.6 + 0x1dd90) #16 0x00007fffef0ddf0c __libc_start_main (libc.so.6 + 0x1df0c) #17 0x00005555582fed10 _start (/home/csmantle/dist/linux-arch/tools/perf/perf + 0x5ed10) ELF object binary architecture: LoongArch ... and it can be confirmed with Valgrind: ==1721834== Invalid free() / delete / delete[] / realloc() ==1721834== at 0x4EA9014: free (in /usr/lib/valgrind/vgpreload_memcheck-loongarch64-linux.so) ==1721834== by 0x4106287: __zfree (zalloc.c:13) ==1721834== by 0x42ADC8F: disasm_line__free (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x429B737: annotated_source__purge (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x42811EB: __hist_entry__tui_annotate (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x42848D7: do_annotate (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x428CF33: evsel__hists_browse (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== Address 0x7d34303 is 35 bytes inside a block of size 62 alloc'd ==1721834== at 0x4EA59B8: malloc (in /usr/lib/valgrind/vgpreload_memcheck-loongarch64-linux.so) ==1721834== by 0x6B80B6F: strdup (strdup.c:42) ==1721834== by 0x42AD917: disasm_line__new (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x42AE5A3: symbol__disassemble_objdump (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x42AF0A7: symbol__disassemble (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x429B3CF: symbol__annotate (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x429C233: symbol__annotate2 (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x42804D3: __hist_entry__tui_annotate (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x42848D7: do_annotate (in /home/csmantle/dist/linux-arch/tools/perf/perf) ==1721834== by 0x428CF33: evsel__hists_browse (in /home/csmantle/dist/linux-arch/tools/perf/perf) This patch adds the missing free() specialization in loongarch_jump_ops, which prevents disasm_line__free() from invoking the default cleanup function. Fixes: fb7fd2a ("perf annotate: Move raw_comment and raw_func_start fields out of 'struct ins_operands'") Cc: stable@vger.kernel.org Cc: WANG Rui <wangrui@loongson.cn> Cc: Huacai Chen <chenhuacai@kernel.org> Cc: WANG Xuerui <kernel@xen0n.name> Cc: loongarch@lists.linux.dev Signed-off-by: Rong Bao <rong.bao@csmantle.top> Tested-by: WANG Rui <wangrui@loongson.cn> Signed-off-by: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ninelore
pushed a commit
that referenced
this pull request
May 12, 2026
commit 3700f07 upstream. MSR_IA32_DEBUGCTLMSR and LBR MSRs are currently not enumerated by KVM_GET_MSR_INDEX_LIST, and LBR MSRs cannot be set with KVM_SET_MSRS. So save/restore is completely broken. Fix it by adding the MSRs to msrs_to_save_base, and allowing writes to LBR MSRs from userspace only (as they are read-only MSRs) if LBR virtualization is enabled. Additionally, to correctly restore L1's LBRs while L2 is running, make sure the LBRs are copied from the captured VMCB01 save area in svm_copy_vmrun_state(). Note, for VMX, this also fixes a flaw where MSR_IA32_DEBUGCTLMSR isn't reported as an MSR to save/restore. Note #2, over-reporting MSR_IA32_LASTxxx on Intel is ok, as KVM already handles unsupported reads and writes thanks to commit b5e2fec ("KVM: Ignore DEBUGCTL MSRs with no effect") (kvm_do_msr_access() will morph the unsupported userspace write into a nop). Fixes: 24e09cb ("KVM: SVM: enable LBR virtualization") Cc: stable@vger.kernel.org Reported-by: Jim Mattson <jmattson@google.com> Signed-off-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260303003421.2185681-4-yosry@kernel.org [sean: guard with lbrv checks, massage changelog] Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ninelore
pushed a commit
that referenced
this pull request
May 12, 2026
commit 96bd3e7 upstream. According to the APM Volume #2, 15.5, Canonicalization and Consistency Checks (24593—Rev. 3.42—March 2024), the following condition (among others) results in a #VMEXIT with VMEXIT_INVALID (aka SVM_EXIT_ERR): EFER.LME, CR0.PG, CR4.PAE, CS.L, and CS.D are all non-zero. In the list of consistency checks done when EFER.LME and CR0.PG are set, add a check that CS.L and CS.D are not both set, after the existing check that CR4.PAE is set. This is functionally a nop because the nested VMRUN results in SVM_EXIT_ERR in HW, which is forwarded to L1, but KVM makes all consistency checks before a VMRUN is actually attempted. Fixes: 3d6368e ("KVM: SVM: Add VMRUN handler") Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260303003421.2185681-17-yosry@kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ninelore
pushed a commit
that referenced
this pull request
May 12, 2026
commit b71138f upstream. From the APM Volume #2, 15.25.4 (24593—Rev. 3.42—March 2024): When VMRUN is executed with nested paging enabled (NP_ENABLE = 1), the following conditions are considered illegal state combinations, in addition to those mentioned in “Canonicalization and Consistency Checks”: • Any MBZ bit of nCR3 is set. • Any G_PAT.PA field has an unsupported type encoding or any reserved field in G_PAT has a nonzero value. Add the consistency check for nCR3 being a legal GPA with no MBZ bits set. Note, the G_PAT.PA check is being handled separately[*]. Link: https://lore.kernel.org/kvm/20260205214326.1029278-3-jmattson@google.com [*] Fixes: 4b16184 ("KVM: SVM: Initialize Nested Nested MMU context on VMRUN") Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260303003421.2185681-16-yosry@kernel.org [sean: capture everything in CC(), massage changelog formatting] Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
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.
Source of the patches:
https://patchew.org/linux/20250523-b4-gs101._5Fmax77759._5Ffg-v4-0-b49904e35a34@uclouvain.be/
Tested on my Pixel 6a and this is letting me see the current battery level