Skip to content
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.

Sign up for GitHub

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

Jump to bottom

arm64: dts: qcom: msm8916: add msm8916-common.dtsi #279

Draft
wants to merge 4 commits into
base: msm8916/6.2-rc4
Choose a base branch
from
Draft

arm64: dts: qcom: msm8916: add msm8916-common.dtsi #279

wants to merge 4 commits into from

Conversation

wonderfulShrineMaidenOfParadise
Copy link

@wonderfulShrineMaidenOfParadise wonderfulShrineMaidenOfParadise commented Jan 15, 2023 •
edited
Loading

The commits add support for Qualcomm MSM8939 SoC with
support for peripherals like I2C, eMMC, WLAN, MDSS and
so on.
The chip is largely based on MSM8916, allowing us to
reuse many of the drivers.

MSM8939 and MSM8916 are similar, with some differences in CPU cores, GPU and clocks,.
The common parts are shared in msm8916-common.dtsi to reduce duplication.

Sadly, it is not capable of using PSCI, but it is possible
to bring up all eight cores with a different approach.

@stephan-gh
Copy link
Member

Thanks for the changes! Right now I'm not comfortable merging this "downstream" into msm8916-mainline, as it diverges too much from what Bryan is working on at Linaro (which is semi-actively being upstreamed).

Having such a common dtsi is something I'd like to consider for a wider range of platforms (at least MSM8916+MSM8939+MSM8909). But it's also untypical for Qualcomm platforms upstream so I imagine getting this in needs careful consideration and very good reasoning. I haven't found time yet to think about this myself in detail though.

If you'd like to work on this further I suggest that you coordinate with Bryan since this is definitely not something we can decide alone here in msm8916-mainline.

@wonderfulShrineMaidenOfParadise wonderfulShrineMaidenOfParadise changed the base branch from msm8916/6.2-rc3 to msm8916/6.2-rc4 January 17, 2023 04:36
@bolilingmeng89006
arm64: dts: qcom: msm8916: add msm8916-common.dtsi
9538ad4 
Signed-off-by: Lin, Meng-Bo <linmengbo0689@protonmail.com>
@bolilingmeng89006
arm64: dts: qcom: msm8939: include msm8916-common.dtsi
b4aad21 
Signed-off-by: Lin, Meng-Bo <linmengbo0689@protonmail.com>
@bolilingmeng89006
squash! arm64: dts: qcom: msm8939-huawei-kiwi
1f1230a 
Signed-off-by: Lin, Meng-Bo <linmengbo0689@protonmail.com>
@bolilingmeng89006
squash! arm64: dts: qcom: msm8939-samsung-a7
4d29bf4 
Signed-off-by: Lin, Meng-Bo <linmengbo0689@protonmail.com>
@wonderfulShrineMaidenOfParadise
Copy link
Author

To be honest I am not a fan of Bryan's solution. I might suggest the common dtsi after his patches applied.

@Boom-Hacker
Copy link

I think it is very harmful for human to look up the code, even if it may be beneficial for compilation.
such as this arch:https://github.com/LineageOS/android_kernel_huawei_kiwi/tree/lineage-17.1/arch/arm/boot/dts/qcom

@wonderfulShrineMaidenOfParadise wonderfulShrineMaidenOfParadise marked this pull request as draft January 28, 2023 12:22
barni2000 pushed a commit to msm8953-mainline/linux that referenced this pull request Jun 21, 2024
@gregkh
ipvlan: Dont Use skb->sk in ipvlan_process_v{4,6}_outbound
13c4543 
[ Upstream commit b3dc6e8 ]

Raw packet from PF_PACKET socket ontop of an IPv6-backed ipvlan device will
hit WARN_ON_ONCE() in sk_mc_loop() through sch_direct_xmit() path.

WARNING: CPU: 2 PID: 0 at net/core/sock.c:775 sk_mc_loop+0x2d/0x70
Modules linked in: sch_netem ipvlan rfkill cirrus drm_shmem_helper sg drm_kms_helper
CPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ msm8916-mainline#279
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
RIP: 0010:sk_mc_loop+0x2d/0x70
Code: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1c
RSP: 0018:ffffa9584015cd78 EFLAGS: 00010212
RAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001
RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000
RBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00
R10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000
R13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000
FS:  0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<IRQ>
 ? __warn (kernel/panic.c:693)
 ? sk_mc_loop (net/core/sock.c:760)
 ? report_bug (lib/bug.c:201 lib/bug.c:219)
 ? handle_bug (arch/x86/kernel/traps.c:239)
 ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1))
 ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621)
 ? sk_mc_loop (net/core/sock.c:760)
 ip6_finish_output2 (net/ipv6/ip6_output.c:83 (discriminator 1))
 ? nf_hook_slow (net/netfilter/core.c:626)
 ip6_finish_output (net/ipv6/ip6_output.c:222)
 ? __pfx_ip6_finish_output (net/ipv6/ip6_output.c:215)
 ipvlan_xmit_mode_l3 (drivers/net/ipvlan/ipvlan_core.c:602) ipvlan
 ipvlan_start_xmit (drivers/net/ipvlan/ipvlan_main.c:226) ipvlan
 dev_hard_start_xmit (net/core/dev.c:3594)
 sch_direct_xmit (net/sched/sch_generic.c:343)
 __qdisc_run (net/sched/sch_generic.c:416)
 net_tx_action (net/core/dev.c:5286)
 handle_softirqs (kernel/softirq.c:555)
 __irq_exit_rcu (kernel/softirq.c:589)
 sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1043)

The warning triggers as this:
packet_sendmsg
   packet_snd //skb->sk is packet sk
      __dev_queue_xmit
         __dev_xmit_skb //q->enqueue is not NULL
             __qdisc_run
               sch_direct_xmit
                 dev_hard_start_xmit
                   ipvlan_start_xmit
                      ipvlan_xmit_mode_l3 //l3 mode
                        ipvlan_process_outbound //vepa flag
                          ipvlan_process_v6_outbound
                            ip6_local_out
                                __ip6_finish_output
                                  ip6_finish_output2 //multicast packet
                                    sk_mc_loop //sk->sk_family is AF_PACKET

Call ip{6}_local_out() with NULL sk in ipvlan as other tunnels to fix this.

Fixes: 2ad7bf3 ("ipvlan: Initial check-in of the IPVLAN driver.")
Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Yue Haibing <yuehaibing@huawei.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/r/20240529095633.613103-1-yuehaibing@huawei.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@wonderfulShrineMaidenOfParadise @stephan-gh @Boom-Hacker @bolilingmeng89006