arm64: dts: qcom: msm8937: Add Huawei Honor 7C - #47
Draft
AztecMX wants to merge 1 commit into
Draft
Conversation
Signed-off-by: AztecMX <aztecmx@proton.me>
Collaborator
|
Can you please share a dmesg? I would like to check if everything is correct |
barni2000
requested changes
Feb 17, 2026
barni2000
left a comment
barni2000
left a comment
Collaborator
There was a problem hiding this comment.
Please use your full name in your SoB?
| dtb-$(CONFIG_ARCH_QCOM) += msm8917-xiaomi-tiare.dtb | ||
| dtb-$(CONFIG_ARCH_QCOM) += msm8917-xiaomi-ugglite.dtb | ||
| dtb-$(CONFIG_ARCH_QCOM) += msm8929-wingtech-wt82918hd.dtb | ||
| dtb-$(CONFIG_ARCH_QCOM) += msm8937-huawei-aum.dtb |
Collaborator
There was a problem hiding this comment.
aum is autumn, i would prefer the full code name like agassi
|
|
||
| / { | ||
| model = "Huawei Honor 7C (aum)"; | ||
| compatible = "huawei,aum", "qcom,msm8937"; |
Collaborator
There was a problem hiding this comment.
Suggested change
| compatible = "huawei,aum", "qcom,msm8937"; | |
| compatible = "huawei,autumn", "qcom,msm8937"; |
| #include "msm8937-qdsp6.dtsi" | ||
|
|
||
| / { | ||
| model = "Huawei Honor 7C (aum)"; |
Collaborator
There was a problem hiding this comment.
Suggested change
| model = "Huawei Honor 7C (aum)"; | |
| model = "Huawei Honor 7C"; |
| chassis-type = "handset"; | ||
| qcom,msm-id = <QCOM_ID_MSM8937 0>; | ||
| qcom,board-id = <8331 0>; | ||
| aliases { |
Collaborator
There was a problem hiding this comment.
Suggested change
| aliases { | |
| aliases { |
| mmc0 = &sdhc_1; | ||
| mmc1 = &sdhc_2; | ||
| }; | ||
| battery: battery { |
Collaborator
There was a problem hiding this comment.
Suggested change
| battery: battery { | |
| battery: battery { |
Collaborator
There was a problem hiding this comment.
Where this battery node is used?
Author
There was a problem hiding this comment.
Where this battery node is used?
This is for cw2015 fuel gauge, I will add it later
| drive-strength = <2>; | ||
| bias-disable; | ||
| }; | ||
| tsp_int_rst_default: tsp-int-rst-default-state { |
Collaborator
There was a problem hiding this comment.
Suggested change
| tsp_int_rst_default: tsp-int-rst-default-state { | |
| tsp_int_rst_default: tsp-int-rst-default-state { |
| drive-strength = <8>; | ||
| bias-pull-up; | ||
| }; | ||
| nfc_int_default: nfc-int-default-state { |
Collaborator
There was a problem hiding this comment.
Suggested change
| nfc_int_default: nfc-int-default-state { | |
| nfc_int_default: nfc-int-default-state { |
|
|
||
| &blsp2_i2c1 { | ||
| status = "okay"; | ||
| nfc@28 { |
Collaborator
There was a problem hiding this comment.
Suggested change
| nfc@28 { | |
| nfc@28 { |
|
|
||
| &blsp1_i2c3 { | ||
| status = "okay"; | ||
| touchscreen@38 { |
Collaborator
There was a problem hiding this comment.
Suggested change
| touchscreen@38 { | |
| touchscreen@38 { |
| }; | ||
| }; | ||
|
|
||
| &usb { |
Collaborator
There was a problem hiding this comment.
It will not work without extcon, you should wire up charger and extcons.
AztecMX
marked this pull request as draft
February 18, 2026 12:03
barni2000
pushed a commit
that referenced
this pull request
May 23, 2026
commit 082a6d0 upstream. Commit 2cd8231 ("mm/slub: allow to set node and align in k[v]realloc") introduced the ability to force a reallocation if the original object does not satisfy new alignment or NUMA node, even when the object is being shrunk. This introduced two bugs in the reallocation fallback path: 1. Data loss during NUMA migration: The jump to 'alloc_new' happens before 'ks' and 'orig_size' are initialized. As a result, the memcpy() in the 'alloc_new' block would copy 0 bytes into the new allocation. 2. Buffer overflow during shrinking: When shrinking an object while forcing a new alignment, 'new_size' is smaller than the old size. However, the memcpy() used the old size ('orig_size ?: ks'), leading to an out-of-bounds write. The same overflow bug exists in the kvrealloc() fallback path, where the old bucket size ksize(p) is copied into the new buffer without being bounded by the new size. A simple reproducer: // e.g. add to lkdtm as KREALLOC_SHRINK_OVERFLOW while (1) { void *p = kmalloc(128, GFP_KERNEL); p = krealloc_node_align(p, 64, 256, GFP_KERNEL, NUMA_NO_NODE); kfree(p); } demonstrates the issue: ================================================================== BUG: KFENCE: out-of-bounds write in memcpy_orig+0x68/0x130 Out-of-bounds write at 0xffff8883ad757038 (120B right of kfence-#47): memcpy_orig+0x68/0x130 krealloc_node_align_noprof+0x1c8/0x340 lkdtm_KREALLOC_SHRINK_OVERFLOW+0x8c/0xc0 [lkdtm] lkdtm_do_action+0x3a/0x60 [lkdtm] ... kfence-#47: 0xffff8883ad756fc0-0xffff8883ad756fff, size=64, cache=kmalloc-64 allocated by task 316 on cpu 7 at 97.680481s (0.021813s ago): krealloc_node_align_noprof+0x19c/0x340 lkdtm_KREALLOC_SHRINK_OVERFLOW+0x8c/0xc0 [lkdtm] lkdtm_do_action+0x3a/0x60 [lkdtm] ... ================================================================== Fix it by moving the old size calculation to the top of __do_krealloc() and bounding all copy lengths by the new allocation size. Fixes: 2cd8231 ("mm/slub: allow to set node and align in k[v]realloc") Cc: stable@vger.kernel.org Reported-by: https://sashiko.dev/#/patchset/20260415143735.2974230-1-elver%40google.com Signed-off-by: Marco Elver <elver@google.com> Link: https://patch.msgid.link/20260416132837.3787694-1-elver@google.com Reviewed-by: Harry Yoo (Oracle) <harry@kernel.org> Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kaloyan501
pushed a commit
to Kaloyan501/linux_msm89x7
that referenced
this pull request
Jul 19, 2026
Commit 2cd8231 ("mm/slub: allow to set node and align in k[v]realloc") introduced the ability to force a reallocation if the original object does not satisfy new alignment or NUMA node, even when the object is being shrunk. This introduced two bugs in the reallocation fallback path: 1. Data loss during NUMA migration: The jump to 'alloc_new' happens before 'ks' and 'orig_size' are initialized. As a result, the memcpy() in the 'alloc_new' block would copy 0 bytes into the new allocation. 2. Buffer overflow during shrinking: When shrinking an object while forcing a new alignment, 'new_size' is smaller than the old size. However, the memcpy() used the old size ('orig_size ?: ks'), leading to an out-of-bounds write. The same overflow bug exists in the kvrealloc() fallback path, where the old bucket size ksize(p) is copied into the new buffer without being bounded by the new size. A simple reproducer: // e.g. add to lkdtm as KREALLOC_SHRINK_OVERFLOW while (1) { void *p = kmalloc(128, GFP_KERNEL); p = krealloc_node_align(p, 64, 256, GFP_KERNEL, NUMA_NO_NODE); kfree(p); } demonstrates the issue: ================================================================== BUG: KFENCE: out-of-bounds write in memcpy_orig+0x68/0x130 Out-of-bounds write at 0xffff8883ad757038 (120B right of kfence-msm89x7-mainline#47): memcpy_orig+0x68/0x130 krealloc_node_align_noprof+0x1c8/0x340 lkdtm_KREALLOC_SHRINK_OVERFLOW+0x8c/0xc0 [lkdtm] lkdtm_do_action+0x3a/0x60 [lkdtm] ... kfence-msm89x7-mainline#47: 0xffff8883ad756fc0-0xffff8883ad756fff, size=64, cache=kmalloc-64 allocated by task 316 on cpu 7 at 97.680481s (0.021813s ago): krealloc_node_align_noprof+0x19c/0x340 lkdtm_KREALLOC_SHRINK_OVERFLOW+0x8c/0xc0 [lkdtm] lkdtm_do_action+0x3a/0x60 [lkdtm] ... ================================================================== Fix it by moving the old size calculation to the top of __do_krealloc() and bounding all copy lengths by the new allocation size. Fixes: 2cd8231 ("mm/slub: allow to set node and align in k[v]realloc") Cc: stable@vger.kernel.org Reported-by: https://sashiko.dev/#/patchset/20260415143735.2974230-1-elver%40google.com Signed-off-by: Marco Elver <elver@google.com> Link: https://patch.msgid.link/20260416132837.3787694-1-elver@google.com Reviewed-by: Harry Yoo (Oracle) <harry@kernel.org> Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
ylecuyer
pushed a commit
to ylecuyer/linux
that referenced
this pull request
Aug 27, 2026
The xfstests' test-case generic/037 fails to execute correctly: FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.15.0-rc4+ msm89x7-mainline#8 SMP PREEMPT_DYNAMIC Thu May 1 16:43:22 PDT 2025 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/037 - output mismatch (see xfstests-dev/results//generic/037.out.bad) The goal of generic/037 test-case is to "verify that replacing a xattr's value is an atomic operation". The test "consists of removing the old value and then inserting the new value in a btree. This made readers (getxattr and listxattrs) not getting neither the old nor the new value during a short time window". The HFS+ has the issue of executing the xattr replace operation because __hfsplus_setxattr() method [1] implemented it as not atomic operation [2]: if (hfsplus_attr_exists(inode, name)) { if (flags & XATTR_CREATE) { pr_err("xattr exists yet\n"); err = -EOPNOTSUPP; goto end_setxattr; } err = hfsplus_delete_attr(inode, name); if (err) goto end_setxattr; err = hfsplus_create_attr(inode, name, value, size); if (err) goto end_setxattr; } The main issue of the logic that it implements delete and create of xattr as independent atomic operations, but the replace operation at whole is not atomic operation. This patch implements a new hfsplus_replace_attr() method that makes the xattr replace operation by atomic one. Also, it reworks hfsplus_create_attr() and hfsplus_delete_attr() with the goal of reusing the common logic in hfsplus_replace_attr() method. sudo ./check generic/037 FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.19.0-rc1+ msm89x7-mainline#47 SMP PREEMPT_DYNAMIC Thu Jan 8 15:37:20 PST 2026 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/037 37s ... 37s Ran: generic/037 Passed all 1 tests [1] https://elixir.bootlin.com/linux/v6.19-rc4/source/fs/hfsplus/xattr.c#L261 [2] https://elixir.bootlin.com/linux/v6.19-rc4/source/fs/hfsplus/xattr.c#L338 Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> cc: Yangtao Li <frank.li@vivo.com> cc: linux-fsdevel@vger.kernel.org Link: https://lore.kernel.org/r/20260109234213.2805400-1-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
ylecuyer
pushed a commit
to ylecuyer/linux
that referenced
this pull request
Aug 27, 2026
The register layout for RZ/T2H is not handled inside cpg_mssr_suspend_noirq() and cpg_mssr_resume_noirq(), causing a memory abort because the wrong code path is taken, as shown below. Explicitly handle the RZ/T2H register layout in cpg_mssr_suspend_noirq() and cpg_mssr_resume_noirq(), similar to how it is done inside cpg_mstp_clock_is_enabled() and cpg_mstp_clock_endisable(). [ 90.052296] Mem abort info: [ 90.055420] ESR = 0x0000000096000007 [ 90.059553] EC = 0x25: DABT (current EL), IL = 32 bits [ 90.065697] SET = 0, FnV = 0 [ 90.069211] EA = 0, S1PTW = 0 [ 90.072834] FSC = 0x07: level 3 translation fault [ 90.078109] Data abort info: [ 90.081405] ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 [ 90.087427] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 90.093169] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 90.099008] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000c60b4000 [ 90.106756] [ffff800082816318] pgd=0000000000000000, p4d=10000000c69ef003, pud=10000000c69f0003, pmd=100000024002b403, pte=0000000000000000 [ 90.120727] Internal error: Oops: 0000000096000007 [msm89x7-mainline#1] SMP [ 90.127058] Modules linked in: sha256 cfg80211 spi_nor at24 renesas_usbhs bluetooth ecdh_generic ecc rfkill rzt2h_adc spi_rzv2h_rspi industrialio_adc gpio_keys fuse drm backlight ipv6 [ 90.145201] CPU: 0 UID: 0 PID: 307 Comm: sh Not tainted 6.18.0-rc1-next-20251016+ msm89x7-mainline#47 PREEMPT [ 90.155006] Hardware name: Renesas RZ/T2H EVK Board based on r9a09g077m44 (DT) [ 90.163041] pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 90.170777] pc : cpg_mssr_suspend_noirq+0x4c/0xc0 [ 90.175983] lr : device_suspend_noirq+0x6c/0x22c [ 90.181309] sp : ffff8000838d3af0 [ 90.185026] x29: ffff8000838d3af0 x28: ffff8000825c016f x27: ffff8000825c01a0 [ 90.192973] x26: ffff8000809feeec x25: ffff8000827bebb8 x24: 0000000000000002 [ 90.200815] x23: ffff8000825c0190 x22: 0000000000000002 x21: 0000000000000000 [ 90.209058] x20: ffff8000827bebb8 x19: ffff000180128010 x18: ffff00033ef92a80 [ 90.217100] x17: ffff000180051700 x16: 0000000000000001 x15: ffff000187afc310 [ 90.224847] x14: 0000000000000254 x13: 0000000000000001 x12: 0000000000000001 [ 90.232793] x11: 00000000000000c0 x10: 0000000000000ab0 x9 : ffff8000838d38b0 [ 90.240540] x8 : ffff000186387410 x7 : 0000000000000001 x6 : 0000000000000000 [ 90.248600] x5 : ffff0001803240d4 x4 : 0000000000000003 x3 : ffff0001803240d0 [ 90.256460] x2 : ffff800082816318 x1 : 000000000000000c x0 : ffff000180324000 [ 90.264208] Call trace: [ 90.267019] cpg_mssr_suspend_noirq+0x4c/0xc0 (P) [ 90.272450] device_suspend_noirq+0x6c/0x22c [ 90.277375] dpm_noirq_suspend_devices+0x1a8/0x2a0 [ 90.282902] dpm_suspend_noirq+0x24/0xa0 [ 90.287428] suspend_devices_and_enter+0x310/0x590 [ 90.292790] pm_suspend+0x1b4/0x200 [ 90.296811] state_store+0x80/0xf4 [ 90.300676] kobj_attr_store+0x18/0x34 [ 90.305002] sysfs_kf_write+0x7c/0x94 [ 90.309232] kernfs_fop_write_iter+0x12c/0x200 [ 90.314115] vfs_write+0x240/0x380 [ 90.318041] ksys_write+0x64/0x100 [ 90.321862] __arm64_sys_write+0x18/0x24 [ 90.326013] invoke_syscall.constprop.0+0x40/0xf0 [ 90.331445] el0_svc_common.constprop.0+0xb8/0xd8 [ 90.336554] do_el0_svc+0x1c/0x28 [ 90.340375] el0_svc+0x34/0xe8 [ 90.343900] el0t_64_sync_handler+0xa0/0xe4 [ 90.348426] el0t_64_sync+0x198/0x19c [ 90.352609] Code: 8b040042 b9409004 7100049f 54000240 (b9400042) [ 90.359639] ---[ end trace 0000000000000000 ]--- Fixes: 065fe72 ("clk: renesas: Add support for R9A09G077 SoC") Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20251127145654.3253992-3-cosmin-gabriel.tanislav.xa@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
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
2 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.
This patch adds initial support of Huawei Honor 7C (huawei-aum)