Add support for Samsung Galaxy A71#44
Conversation
JIaxyga
left a comment
There was a problem hiding this comment.
This is just a quick review. Please fix all of this first of all
| @@ -0,0 +1,788 @@ | |||
| // SPDX-License-Identifier: BSD-3-Clause | |||
| /* | |||
| * Copyright (c) 2023, Danila Tikhonov <danila@jiaxyga.com> | |||
There was a problem hiding this comment.
Add your copyright too if you want
| }; | ||
|
|
||
| /* Limit CPU clock to 2.2 GHz */ | ||
| &cpu6_opp14 { |
| chassis-type = "handset"; | ||
|
|
||
| qcom,msm-id = <QCOM_ID_SM7150 0>; | ||
| qcom,board-id = <34 0>, /* Rev0.0 */ |
There was a problem hiding this comment.
msm-id and board-id are not required when using header v2. If there is no reason to use another header version, then drop it
| wifi0 = &wifi; | ||
| }; | ||
|
|
||
| battery: battery { |
There was a problem hiding this comment.
Are you sure Samsung uses qcom pmic for fg?
There was a problem hiding this comment.
qcom,qgauge@4800 is enabled in the downstream device tree if that's what you mean.
| qcom,pmic-id = "a"; | ||
|
|
||
| vreg_s4a_1p1: smps4 { | ||
| regulator-min-microvolt = <824000>; |
There was a problem hiding this comment.
Add the regulator-name property to each regulator
| bias-disable = <0x00>; | ||
| }; | ||
|
|
||
| sde_esd_suspend: sde-esd-state { |
There was a problem hiding this comment.
Same pin configuration as sde_dsi suspend. Extend the pin list of sde_dsi_suspend instead of a separate node
| }; | ||
|
|
||
| &dispcc { | ||
| status = "okay"; |
There was a problem hiding this comment.
I don't see dispcc being disabled:
https://github.com/sm7150-mainline/linux/blob/v6.14/arch/arm64/boot/dts/qcom/sm7150.dtsi#L3973
|
|
||
| &i2c0 { | ||
| clock-frequency = <100000>; | ||
| status = "okay"; |
There was a problem hiding this comment.
Maybe you could at least leave a comment on what devices are connected? How can we be sure that this bus is used at all? Otherwise just don't enable i2cX until needed. I'm almost certainly sure that one of these buses is not used on your board, and the pins from the bus were reused. This is why you have a crashes when you enable gpi1
| }; | ||
|
|
||
| / { | ||
| model = "Samsung A71"; |
| @@ -1062,4 +1062,14 @@ config DRM_PANEL_XINPENG_XPP055C272 | |||
| Say Y here if you want to enable support for the Xinpeng | |||
There was a problem hiding this comment.
Write dt-bindings for the panel driver
| * If it's not set at all the display won't show anything because reset-gpios is required by the driver. | ||
| */ | ||
| reset-gpios = <&tlmm 9 GPIO_ACTIVE_HIGH>; // TODO: Check this again or fix in driver | ||
| reset-gpios = <&tlmm 11 GPIO_ACTIVE_HIGH>; |
There was a problem hiding this comment.
your reset gpio is almost certainly active low and that should fix all your problems
|
This now only includes the device tree adition |
Add device tree for the Samsung Galaxy A71 (a715f) smartphone. This device is based on Snapdragon 730G (sm7150) SoC. Co-developed-by: Danila Tikhonov <danila@jiaxyga.com>
…() after confirm When send a broadcast packet to a tap device, which was added to a bridge, br_nf_local_in() is called to confirm the conntrack. If another conntrack with the same hash value is added to the hash table, which can be triggered by a normal packet to a non-bridge device, the below warning may happen. ------------[ cut here ]------------ WARNING: CPU: 1 PID: 96 at net/bridge/br_netfilter_hooks.c:632 br_nf_local_in+0x168/0x200 CPU: 1 UID: 0 PID: 96 Comm: tap_send Not tainted 6.17.0-rc2-dirty #44 PREEMPT(voluntary) RIP: 0010:br_nf_local_in+0x168/0x200 Call Trace: <TASK> nf_hook_slow+0x3e/0xf0 br_pass_frame_up+0x103/0x180 br_handle_frame_finish+0x2de/0x5b0 br_nf_hook_thresh+0xc0/0x120 br_nf_pre_routing_finish+0x168/0x3a0 br_nf_pre_routing+0x237/0x5e0 br_handle_frame+0x1ec/0x3c0 __netif_receive_skb_core+0x225/0x1210 __netif_receive_skb_one_core+0x37/0xa0 netif_receive_skb+0x36/0x160 tun_get_user+0xa54/0x10c0 tun_chr_write_iter+0x65/0xb0 vfs_write+0x305/0x410 ksys_write+0x60/0xd0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> ---[ end trace 0000000000000000 ]--- To solve the hash conflict, nf_ct_resolve_clash() try to merge the conntracks, and update skb->_nfct. However, br_nf_local_in() still use the old ct from local variable 'nfct' after confirm(), which leads to this warning. If confirm() does not insert the conntrack entry and return NF_DROP, the warning may also occur. There is no need to reserve the WARN_ON_ONCE, just remove it. Link: https://lore.kernel.org/netdev/20250820043329.2902014-1-wangliang74@huawei.com/ Fixes: 62e7151 ("netfilter: bridge: confirm multicast packets before passing them up the stack") Suggested-by: Florian Westphal <fw@strlen.de> Signed-off-by: Wang Liang <wangliang74@huawei.com> Signed-off-by: Florian Westphal <fw@strlen.de>
…aths
Several iso_pi(sk) fields (qos, qos_user_set, bc_sid, base, base_len,
sync_handle, bc_num_bis) are written under lock_sock in
iso_sock_setsockopt() and iso_sock_bind(), but read and written under
hci_dev_lock only in two other paths:
- iso_connect_bis() / iso_connect_cis(), invoked from connect(2),
read qos/base/bc_sid and reset qos to default_qos on the
qos_user_set validation failure -- all without lock_sock.
- iso_connect_ind(), invoked from hci_rx_work, writes sync_handle,
bc_sid, qos.bcast.encryption, bc_num_bis, base and base_len on
PA_SYNC_ESTABLISHED / PAST_RECEIVED / BIG_INFO_ADV_REPORT /
PER_ADV_REPORT events. The BIG_INFO handler additionally passes
&iso_pi(sk)->qos together with sync_handle / bc_num_bis / bc_bis
to hci_conn_big_create_sync() while setsockopt may be mutating
them.
Acquire lock_sock around the affected accesses in both paths.
The locking order hci_dev_lock -> lock_sock matches the existing
iso_conn_big_sync() precedent, whose comment documents the same
requirement for hci_conn_big_create_sync(). The HCI connect/bind
helpers do not wait for command completion -- they enqueue work via
hci_cmd_sync_queue{,_once}() / hci_le_create_cis_pending() and
return -- so the added hold time is comparable to iso_conn_big_sync().
KCSAN report:
BUG: KCSAN: data-race in iso_connect_cis / iso_sock_setsockopt
read to 0xffffa3ae8ce3cdc8 of 1 bytes by task 335 on cpu 0:
iso_connect_cis+0x49f/0xa20
iso_sock_connect+0x60e/0xb40
__sys_connect_file+0xbd/0xe0
__sys_connect+0xe0/0x110
__x64_sys_connect+0x40/0x50
x64_sys_call+0xcad/0x1c60
do_syscall_64+0x133/0x590
entry_SYSCALL_64_after_hwframe+0x77/0x7f
write to 0xffffa3ae8ce3cdc8 of 60 bytes by task 334 on cpu 1:
iso_sock_setsockopt+0x69a/0x930
do_sock_setsockopt+0xc3/0x170
__sys_setsockopt+0xd1/0x130
__x64_sys_setsockopt+0x64/0x80
x64_sys_call+0x1547/0x1c60
do_syscall_64+0x133/0x590
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Reported by Kernel Concurrency Sanitizer on:
CPU: 1 UID: 0 PID: 334 Comm: iso_setup_race Not tainted 7.0.0-10949-g8541d8f725c6 sm7150-mainline#44 PREEMPT(lazy)
The iso_connect_ind() races were found by inspection.
Fixes: ccf74f2 ("Bluetooth: Add BTPROTO_ISO socket type")
Signed-off-by: SeungJu Cheon <suunj1331@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The xfstests' test-case generic/637 fails with error: FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.15.0-rc4+ sm7150-mainline#8 SMP PREEMPT_DYNAMIC Thu May 1 16:43:22 PDT 2025 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch QA output created by 637 entries 7 and 8 have duplicate d_off 8 Found unlinked files in open dir (see xfstests-dev/results//generic/637.full for details) Debugging of the hfsplus_readdir() logic showed this: hfsplus: hfsplus_readdir(): 163 ctx->pos 0 hfsplus: hfsplus_readdir(): 189 ctx->pos 1 hfsplus: hfsplus_readdir(): 264 ctx->pos 2, ino 18 hfsplus: hfsplus_readdir(): 264 ctx->pos 3, ino 19 hfsplus: hfsplus_readdir(): 264 ctx->pos 4, ino 28 hfsplus: hfsplus_readdir(): 264 ctx->pos 5, ino 118 hfsplus: hfsplus_readdir(): 264 ctx->pos 6, ino 29 hfsplus: hfsplus_readdir(): 264 ctx->pos 7, ino 30 hfsplus: hfsplus_readdir(): 264 ctx->pos 8, ino 31 hfsplus: hfsplus_readdir(): 304 ctx->pos 8 hfsplus: hfsplus_unlink():420 dir->i_ino 17, inode->i_ino 28 hfsplus: hfsplus_readdir(): 141 ctx->pos 7 hfsplus: hfsplus_readdir(): 264 ctx->pos 7, ino 31 hfsplus: hfsplus_readdir(): 264 ctx->pos 8, ino 32 hfsplus: hfsplus_readdir(): 264 ctx->pos 9, ino 33 It means that hfsplus_readdir() stopped the processing of folder's items on ctx->pos 8, then, item with ino 28 has been deleted and hfsplus_readdir() re-started the logic from ctx->pos 7. As a result, previous and new sets of folder's items have overlapping values for the case of d_off 8. Currently, HFS+ has very complicated and fragile logic of rd->file->f_pos correction in hfsplus_delete_cat(). This patch removes this logic and it stores the current pos into hfsplus_readdir_data. Finally, if rd->pos == ctx->pos then hfsplus_readdir() tries to find the position in b-tree's node by means of hfsplus_cat_key. This position is used to re-start the folder's content traversal. sudo ./check generic/637 FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 7.1.0-rc1+ sm7150-mainline#44 SMP PREEMPT_DYNAMIC Mon May 4 15:58:45 PDT 2026 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/637 22s ... 22s Ran: generic/637 Passed all 1 tests Closes: hfs-linux-kernel#198 cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> cc: Yangtao Li <frank.li@vivo.com> cc: linux-fsdevel@vger.kernel.org Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> Link: https://lore.kernel.org/r/20260505220051.2854696-2-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
Kernel dmesg reports IRQ sm7150-mainline#44 being disabled due to unhandled interrupts from multiple PCA953x IO expanders: [ 447.047861] irq 44: nobody cared (try booting with the "irqpoll" option) [ 447.063124] handlers: [ 447.068176] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler [ 447.087268] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler [ 447.106344] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler [ 447.125421] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler [ 447.144513] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler [ 447.163587] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler [ 447.182663] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler [ 447.201756] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler [ 447.220837] Disabling IRQ sm7150-mainline#44 The affected IOEXP nodes are missing interrupt pin configuration in the device tree, causing the interrupt line to remain asserted and resulting in repeated unhandled IRQ events. Add the required interrupt-related properties for the affected IOEXP devices to ensure proper interrupt handling and prevent the IRQ from being disabled. [arj: Drop markdown code-block fence, favour indentation] Signed-off-by: Potin Lai <potin.lai@quantatw.com> Link: https://patch.msgid.link/20260523-potin-update-sanmiguel-dts-20260522-v1-1-169f5fceb5f9@quantatw.com Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
This includes device-tree and generated panel driver.