5.15.166-rc1 review
Subsystems (3)
Greg Kroah-Hartman
maintainerPATCH 146/215 net: dsa: mv88e6xxx: replace ATU violation prints with trace points
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vladimir Oltean <[email protected]>
[ Upstream commit 8646384d80f3d3b4a66b3284dbbd8232d1b8799e ]
In applications where the switch ports must perform 802.1X based authentication and are therefore locked, ATU violation interrupts are quite to be expected as part of normal operation. The problem is that they currently spam the kernel log, even if rate limited.
Create a series of trace points, all derived from the same event class, which log these violations to the kernel's trace buffer, which is both much faster and much easier to ignore than printing to a serial console.
New usage model:
$ trace-cmd list | grep mv88e6xxx mv88e6xxx mv88e6xxx:mv88e6xxx_atu_full_violation mv88e6xxx:mv88e6xxx_atu_miss_violation mv88e6xxx:mv88e6xxx_atu_member_violation $ trace-cmd record -e mv88e6xxx sleep 10
Stable-dep-of: 528876d867a2 ("net: dsa: mv88e6xxx: Fix out-of-bound access")
--- drivers/net/dsa/mv88e6xxx/Makefile | 4 ++ drivers/net/dsa/mv88e6xxx/global1_atu.c | 19 +++---- drivers/net/dsa/mv88e6xxx/trace.c | 6 +++ drivers/net/dsa/mv88e6xxx/trace.h | 66 +++++++++++++++++++++++++ 4 files changed, 86 insertions(+), 9 deletions(-) create mode 100644 drivers/net/dsa/mv88e6xxx/trace.c create mode 100644 drivers/net/dsa/mv88e6xxx/trace.h
drivers/net/dsa/mv88e6xxx/Makefile +4 -0
@@ -15,3 +15,7 @@ mv88e6xxx-objs += port_hidden.o mv88e6xxx-$(CONFIG_NET_DSA_MV88E6XXX_PTP) += ptp.o mv88e6xxx-objs += serdes.o mv88e6xxx-objs += smi.o +mv88e6xxx-objs += trace.o + +# for tracing framework to find trace.h +CFLAGS_trace.o := -I$(src)
drivers/net/dsa/mv88e6xxx/global1_atu.c +10 -9
@@ -12,6 +12,7 @@#include "chip.h" #include "global1.h" +#include "trace.h" /* Offset 0x01: ATU FID Register */
@@ -435,23 +436,23 @@ static irqreturn_t mv88e6xxx_g1_atu_prob_irq_thread_fn(int irq, void *dev_id) }if (val &MV88E6XXX_G1_ATU_OP_MEMBER_VIOLATION ) { -dev_err_ratelimited (chip->dev, -"ATU member violation for %pM fid %u portvec %x spid %d\n" , - entry.mac, fid, entry.portvec, spid); +trace_mv88e6xxx_atu_member_violation (chip->dev, spid, + entry.portvec, entry.mac, + fid); chip->ports[spid].atu_member_violation++; }if (val &MV88E6XXX_G1_ATU_OP_MISS_VIOLATION ) { -dev_err_ratelimited (chip->dev, -"ATU miss violation for %pM fid %u portvec %x spid %d\n" , - entry.mac, fid, entry.portvec, spid); +trace_mv88e6xxx_atu_miss_violation (chip->dev, spid, + entry.portvec, entry.mac, + fid); chip->ports[spid].atu_miss_violation++; }if (val &MV88E6XXX_G1_ATU_OP_FULL_VIOLATION ) { -dev_err_ratelimited (chip->dev, -"ATU full violation for %pM fid %u portvec %x spid %d\n" , - entry.mac, fid, entry.portvec, spid); +trace_mv88e6xxx_atu_full_violation (chip->dev, spid, + entry.portvec, entry.mac, + fid); chip->ports[spid].atu_full_violation++; }mv88e6xxx_reg_unlock (chip);
drivers/net/dsa/mv88e6xxx/trace.c new file +6 -0
@@ -0,0 +1,6 @@ +// SPDX-License-Identifier: GPL-2.0-or-later +/* Copyright 2022 NXP +*/ + +#define CREATE_TRACE_POINTS +#include "trace.h"
drivers/net/dsa/mv88e6xxx/trace.h new file +66 -0
66 lines not on this page · raw message
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 147/215 net: dsa: mv88e6xxx: Fix out-of-bound access
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joseph Huang <[email protected]>
[ Upstream commit 528876d867a23b5198022baf2e388052ca67c952 ]
If an ATU violation was caused by a CPU Load operation, the SPID could be larger than DSA_MAX_PORTS (the size of mv88e6xxx_chip.ports[] array).
--- drivers/net/dsa/mv88e6xxx/global1_atu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/dsa/mv88e6xxx/global1_atu.c +2 -1
@@ -453,7 +453,8 @@ static irqreturn_t mv88e6xxx_g1_atu_prob_irq_thread_fn(int irq, void *dev_id)trace_mv88e6xxx_atu_full_violation (chip->dev, spid, entry.portvec, entry.mac, fid); - chip->ports[spid].atu_full_violation++; +if (spid <ARRAY_SIZE (chip->ports)) + chip->ports[spid].atu_full_violation++; }mv88e6xxx_reg_unlock (chip);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 148/215 netem: fix return value if duplicate enqueue fails
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stephen Hemminger <[email protected]>
[ Upstream commit c07ff8592d57ed258afee5a5e04991a48dbaf382 ]
There is a bug in netem_enqueue() introduced by
commit 5845f706388a ("net: netem: fix skb length BUG_ON in __skb_to_sgvec") that can lead to a use-after-free.
This commit made netem_enqueue() always return NET_XMIT_SUCCESS when a packet is duplicated, which can cause the parent qdisc's q.qlen to be mistakenly incremented. When this happens qlen_notify() may be skipped on the parent during destruction, leaving a dangling pointer for some classful qdiscs like DRR.
There are two ways for the bug happen:
- If the duplicated packet is dropped by rootq->enqueue() and then the original packet is also dropped.
- If rootq->enqueue() sends the duplicated packet to a different qdisc and the original packet is dropped.
In both cases NET_XMIT_SUCCESS is returned even though no packets are enqueued at the netem qdisc.
The fix is to defer the enqueue of the duplicate packet until after the original packet has been guaranteed to return NET_XMIT_SUCCESS.
--- net/sched/sch_netem.c | 47 ++++++++++++++++++++++++++----------------- 1 file changed, 29 insertions(+), 18 deletions(-)
net/sched/sch_netem.c +29 -18
@@ -437,12 +437,10 @@ static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch,struct netem_sched_data *q =qdisc_priv (sch);/* We don't fill cb now as skb_unshare() may invalidate it */ struct netem_skb_cb *cb; -struct sk_buff *skb2; +struct sk_buff *skb2 =NULL ;struct sk_buff *segs =NULL ;unsigned int prev_len =qdisc_pkt_len (skb);int count =1 ; -int rc =NET_XMIT_SUCCESS ; -int rc_drop =NET_XMIT_DROP ;/* Do not fool qdisc_drop_all() */ skb->prev =NULL ;
@@ -471,19 +469,11 @@ static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch,skb_orphan_partial (skb);/* -* If we need to duplicate packet, then re-insert at top of the -* qdisc tree, since parent queuer expects that only one -* skb will be queued. +* If we need to duplicate packet, then clone it before +* original is modified. */ -if (count >1 && (skb2 =skb_clone (skb,GFP_ATOMIC )) !=NULL ) { -struct Qdisc *rootq =qdisc_root_bh (sch); -u32 dupsave = q->duplicate;/* prevent duplicating a dup... */ - - q->duplicate =0 ; - rootq->enqueue (skb2, rootq, to_free); - q->duplicate = dupsave; - rc_drop =NET_XMIT_SUCCESS ; - } +if (count >1 ) + skb2 =skb_clone (skb,GFP_ATOMIC );/* * Randomized packet corruption.
@@ -495,7 +485,8 @@ static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch,if (skb_is_gso (skb)) { skb =netem_segment (skb, sch, to_free);if (!skb) -return rc_drop; + goto finish_segs; + segs = skb->next;skb_mark_not_on_list (skb);qdisc_skb_cb (skb)->pkt_len = skb->len;
@@ -521,7 +512,24 @@ static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch,/* re-link segs, so that qdisc_drop_all() frees them all */ skb->next = segs;qdisc_drop_all (skb, sch, to_free); -return rc_drop; +if (skb2) +__qdisc_drop (skb2, to_free); +return NET_XMIT_DROP ; + } + +/* +* If doing duplication then re-insert at top of the +* qdisc tree, since parent queuer expects that only one +* skb will be queued. +*/ +if (skb2) { +struct Qdisc *rootq =qdisc_root_bh (sch); +u32 dupsave = q->duplicate;/* prevent duplicating a dup... */ + + q->duplicate =0 ; + rootq->enqueue (skb2, rootq, to_free); + q->duplicate = dupsave; + skb2 =NULL ; }qdisc_qstats_backlog_inc (sch, skb);
@@ -592,9 +600,12 @@ static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch, } finish_segs: +if (skb2) +__qdisc_drop (skb2, to_free); +if (segs) {unsigned int len, last_len; -int nb; +int rc, nb; len = skb ? skb->len :0 ; nb = skb ?1 :0 ;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 149/215 ipv6: prevent UAF in ip6_send_skb()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit faa389b2fbaaec7fd27a390b4896139f9da662e3 ]
syzbot reported an UAF in ip6_send_skb() [1]
After ip6_local_out() has returned, we no longer can safely dereference rt, unless we hold rcu_read_lock().
A similar issue has been fixed in commit a688caa34beb ("ipv6: take rcu lock in rawv6_send_hdrinc()")
Another potential issue in ip6_finish_output2() is handled in a separate patch.
[1]
BUG: KASAN: slab-use-after-free in ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964 Read of size 8 at addr ffff88806dde4858 by task syz.1.380/6530 CPU: 1 UID: 0 PID: 6530 Comm: syz.1.380 Not tainted 6.11.0-rc3-syzkaller-00306-gdf6cbc62cc9b #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964 rawv6_push_pending_frames+0x75c/0x9e0 net/ipv6/raw.c:588 rawv6_sendmsg+0x19c7/0x23c0 net/ipv6/raw.c:926 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 sock_write_iter+0x2dd/0x400 net/socket.c:1160 do_iter_readv_writev+0x60a/0x890 vfs_writev+0x37c/0xbb0 fs/read_write.c:971 do_writev+0x1b1/0x350 fs/read_write.c:1018 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f936bf79e79 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f936cd7f038 EFLAGS: 00000246 ORIG_RAX: 0000000000000014 RAX: ffffffffffffffda RBX: 00007f936c115f80 RCX: 00007f936bf79e79 RDX: 0000000000000001 RSI: 0000000020000040 RDI: 0000000000000004 RBP: 00007f936bfe7916 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f936c115f80 R15: 00007fff2860a7a8 </TASK> Allocated by task 6530: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:312 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3988 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_noprof+0x135/0x2a0 mm/slub.c:4044 dst_alloc+0x12b/0x190 net/core/dst.c:89 ip6_blackhole_route+0x59/0x340 net/ipv6/route.c:2670 make_blackhole net/xfrm/xfrm_policy.c:3120 [inline] xfrm_lookup_route+0xd1/0x1c0 net/xfrm/xfrm_policy.c:3313 ip6_dst_lookup_flow+0x13e/0x180 net/ipv6/ip6_output.c:1257 rawv6_sendmsg+0x1283/0x23c0 net/ipv6/raw.c:898 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 45: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kmem_cache_free+0x145/0x350 mm/slub.c:4548 dst_destroy+0x2ac/0x460 net/core/dst.c:124 rcu_do_batch kernel/rcu/tree.c:2569 [inline] rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2843 handle_softirqs+0x2c4/0x970 kernel/softirq.c:554 __do_softirq kernel/softirq.c:588 [inline] invoke_softirq kernel/softirq.c:428 [inline] __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637 irq_exit_rcu+0x9/0x30 kernel/softirq.c:649 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702 Last potentially related work creation: kasan_save_stack+0x3f/0x60 mm/kasan/common.c:47 __kasan_record_aux_stack+0xac/0xc0 mm/kasan/generic.c:541 __call_rcu_common kernel/rcu/tree.c:3106 [inline] call_rcu+0x167/0xa70 kernel/rcu/tree.c:3210 refdst_drop include/net/dst.h:263 [inline] skb_dst_drop include/net/dst.h:275 [inline] nf_ct_frag6_queue net/ipv6/netfilter/nf_conntrack_reasm.c:306 [inline] nf_ct_frag6_gather+0xb9a/0x2080 net/ipv6/netfilter/nf_conntrack_reasm.c:485 ipv6_defrag+0x2c8/0x3c0 net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:67 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip6_local_out+0x6fa/0x800 net/ipv6/output_core.c:143 ip6_local_out+0x26/0x70 net/ipv6/output_core.c:153 ip6_send_skb+0x112/0x230 net/ipv6/ip6_output.c:1959 rawv6_push_pending_frames+0x75c/0x9e0 net/ipv6/raw.c:588 rawv6_sendmsg+0x19c7/0x23c0 net/ipv6/raw.c:926 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 sock_write_iter+0x2dd/0x400 net/socket.c:1160 do_iter_readv_writev+0x60a/0x890
--- net/ipv6/ip6_output.c | 2 ++ 1 file changed, 2 insertions(+)
net/ipv6/ip6_output.c +2 -0
@@ -1940,6 +1940,7 @@ int ip6_send_skb(struct sk_buff *skb)struct rt6_info *rt = (struct rt6_info *)skb_dst (skb);int err; +rcu_read_lock (); err =ip6_local_out (net, skb->sk, skb);if (err) {if (err >0 )
@@ -1949,6 +1950,7 @@ int ip6_send_skb(struct sk_buff *skb) IPSTATS_MIB_OUTDISCARDS); } +rcu_read_unlock ();return err; }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 150/215 ipv6: fix possible UAF in ip6_finish_output2()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit da273b377ae0d9bd255281ed3c2adb228321687b ]
If skb_expand_head() returns NULL, skb has been freed and associated dst/idev could also have been freed.
We need to hold rcu_read_lock() to make sure the dst and associated idev are alive.
--- net/ipv6/ip6_output.c | 4 ++++ 1 file changed, 4 insertions(+)
net/ipv6/ip6_output.c +4 -0
@@ -69,11 +69,15 @@ static int ip6_finish_output2(struct net *net, struct sock *sk, struct sk_buff */* Be paranoid, rather than too clever. */ if (unlikely (hh_len >skb_headroom (skb)) && dev->header_ops) { +/* Make sure idev stays alive */ +rcu_read_lock (); skb =skb_expand_head (skb, hh_len);if (!skb) {IP6_INC_STATS (net, idev,IPSTATS_MIB_OUTDISCARDS ); +rcu_read_unlock ();return -ENOMEM ; } +rcu_read_unlock (); } hdr =ipv6_hdr (skb);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 151/215 ipv6: prevent possible UAF in ip6_xmit()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 2d5ff7e339d04622d8282661df36151906d0e1c7 ]
If skb_expand_head() returns NULL, skb has been freed and the associated dst/idev could also have been freed.
We must use rcu_read_lock() to prevent a possible UAF.
--- net/ipv6/ip6_output.c | 4 ++++ 1 file changed, 4 insertions(+)
net/ipv6/ip6_output.c +4 -0
@@ -273,11 +273,15 @@ int ip6_xmit(const struct sock *sk, struct sk_buff *skb, struct flowi6 *fl6, head_room += opt->opt_nflen + opt->opt_flen;if (unlikely (head_room >skb_headroom (skb))) { +/* Make sure idev stays alive */ +rcu_read_lock (); skb =skb_expand_head (skb, head_room);if (!skb) {IP6_INC_STATS (net, idev,IPSTATS_MIB_OUTDISCARDS ); +rcu_read_unlock ();return -ENOBUFS ; } +rcu_read_unlock (); }if (opt) {
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 152/215 netfilter: flowtable: validate vlan header
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pablo Neira Ayuso <[email protected]>
[ Upstream commit 6ea14ccb60c8ab829349979b22b58a941ec4a3ee ]
Ensure there is sufficient room to access the protocol field of the VLAN header, validate it once before the flowtable lookup.
=====================================================
BUG: KMSAN: uninit-value in nf_flow_offload_inet_hook+0x45a/0x5f0 net/netfilter/nf_flow_table_inet.c:32 nf_flow_offload_inet_hook+0x45a/0x5f0 net/netfilter/nf_flow_table_inet.c:32 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook_ingress include/linux/netfilter_netdev.h:34 [inline] nf_ingress net/core/dev.c:5440 [inline]
--- net/netfilter/nf_flow_table_inet.c | 3 +++ net/netfilter/nf_flow_table_ip.c | 3 +++ 2 files changed, 6 insertions(+)
net/netfilter/nf_flow_table_inet.c +3 -0
@@ -17,6 +17,9 @@ nf_flow_offload_inet_hook(void *priv, struct sk_buff *skb,switch (skb->protocol) {case htons (ETH_P_8021Q ): +if (!pskb_may_pull (skb,skb_mac_offset (skb) +sizeof (*veth))) +return NF_ACCEPT ; + veth = (struct vlan_ethhdr *)skb_mac_header (skb); proto = veth->h_vlan_encapsulated_proto;break ;
net/netfilter/nf_flow_table_ip.c +3 -0
@@ -254,6 +254,9 @@ static bool nf_flow_skb_encap_protocol(struct sk_buff *skb, __be16 proto,switch (skb->protocol) {case htons (ETH_P_8021Q ): +if (!pskb_may_pull (skb,skb_mac_offset (skb) +sizeof (*veth))) +return false; + veth = (struct vlan_ethhdr *)skb_mac_header (skb);if (veth->h_vlan_encapsulated_proto == proto) { *offset +=VLAN_HLEN ;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 153/215 net: xilinx: axienet: Always disable promiscuous mode
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sean Anderson <[email protected]>
[ Upstream commit 4ae738dfef2c0323752ab81786e2d298c9939321 ]
If promiscuous mode is disabled when there are fewer than four multicast addresses, then it will not be reflected in the hardware. Fix this by always clearing the promiscuous mode flag even when we program multicast addresses.
--- drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/net/ethernet/xilinx/xilinx_axienet_main.c +4 -0
@@ -427,6 +427,10 @@ static void axienet_set_multicast_list(struct net_device *ndev) }else if (!netdev_mc_empty (ndev)) {struct netdev_hw_addr *ha; + reg =axienet_ior (lp,XAE_FMI_OFFSET ); + reg &= ~XAE_FMI_PM_MASK ; +axienet_iow (lp,XAE_FMI_OFFSET , reg); + i =0 ;netdev_for_each_mc_addr (ha, ndev) {if (i >=XAE_MULTICAST_CAM_TABLE_NUM )
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 154/215 net: xilinx: axienet: Fix dangling multicast addresses
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sean Anderson <[email protected]>
[ Upstream commit 797a68c9de0f5a5447baf4bd3bb9c10a3993435b ]
If a multicast address is removed but there are still some multicast addresses, that address would remain programmed into the frame filter. Fix this by explicitly setting the enable bit for each filter.
--- drivers/net/ethernet/xilinx/xilinx_axienet.h | 1 + .../net/ethernet/xilinx/xilinx_axienet_main.c | 21 ++++++++----------- 2 files changed, 10 insertions(+), 12 deletions(-)
drivers/net/ethernet/xilinx/xilinx_axienet.h +1 -0
@@ -169,6 +169,7 @@#define XAE_UAW0_OFFSET 0x00000700/* Unicast address word 0 */ #define XAE_UAW1_OFFSET 0x00000704/* Unicast address word 1 */ #define XAE_FMI_OFFSET 0x00000708/* Frame Filter Control */ +#define XAE_FFE_OFFSET 0x0000070C/* Frame Filter Enable */ #define XAE_AF0_OFFSET 0x00000710/* Address Filter 0 */ #define XAE_AF1_OFFSET 0x00000714/* Address Filter 1 */
drivers/net/ethernet/xilinx/xilinx_axienet_main.c +9 -12
@@ -409,7 +409,7 @@ static int netdev_set_mac_address(struct net_device *ndev, void *p)*/ static void axienet_set_multicast_list (struct net_device *ndev) { -int i; +int i =0 ;u32 reg, af0reg, af1reg;struct axienet_local *lp =netdev_priv (ndev);
@@ -431,7 +431,6 @@ static void axienet_set_multicast_list(struct net_device *ndev) reg &= ~XAE_FMI_PM_MASK ;axienet_iow (lp,XAE_FMI_OFFSET , reg); - i =0 ;netdev_for_each_mc_addr (ha, ndev) {if (i >=XAE_MULTICAST_CAM_TABLE_NUM )break ;
@@ -450,6 +449,7 @@ static void axienet_set_multicast_list(struct net_device *ndev)axienet_iow (lp,XAE_FMI_OFFSET , reg);axienet_iow (lp,XAE_AF0_OFFSET , af0reg);axienet_iow (lp,XAE_AF1_OFFSET , af1reg); +axienet_iow (lp,XAE_FFE_OFFSET ,1 ); i++; } }else {
@@ -457,18 +457,15 @@ static void axienet_set_multicast_list(struct net_device *ndev) reg &= ~XAE_FMI_PM_MASK ;axienet_iow (lp,XAE_FMI_OFFSET , reg); - -for (i =0 ; i <XAE_MULTICAST_CAM_TABLE_NUM ; i++) { - reg =axienet_ior (lp,XAE_FMI_OFFSET ) &0xFFFFFF00 ; - reg |= i; - -axienet_iow (lp,XAE_FMI_OFFSET , reg); -axienet_iow (lp,XAE_AF0_OFFSET ,0 ); -axienet_iow (lp,XAE_AF1_OFFSET ,0 ); - } -dev_info (&ndev->dev,"Promiscuous mode disabled.\n" ); } + +for (; i <XAE_MULTICAST_CAM_TABLE_NUM ; i++) { + reg =axienet_ior (lp,XAE_FMI_OFFSET ) &0xFFFFFF00 ; + reg |= i; +axienet_iow (lp,XAE_FMI_OFFSET , reg); +axienet_iow (lp,XAE_FFE_OFFSET ,0 ); + } }/**
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 155/215 drm/msm/dpu: dont play tricks with debug macros
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dmitry Baryshkov <[email protected]>
[ Upstream commit df24373435f5899a2a98b7d377479c8d4376613b ]
DPU debugging macros need to be converted to a proper drm_debug_* macros, however this is a going an intrusive patch, not suitable for a fix. Wire DPU_DEBUG and DPU_DEBUG_DRIVER to always use DRM_DEBUG_DRIVER to make sure that DPU debugging messages always end up in the drm debug messages and are controlled via the usual drm.debug mask.
I don't think that it is a good idea for a generic DPU_DEBUG macro to be tied to DRM_UT_KMS. It is used to report a debug message from driver, so by default it should go to the DRM_UT_DRIVER channel. While refactoring debug macros later on we might end up with particular messages going to ATOMIC or KMS, but DRIVER should be the default.
Patchwork: https://patchwork.freedesktop.org/patch/606932/
--- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 14 ++------------ 1 file changed, 2 insertions(+), 12 deletions(-)
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h +2 -12
@@ -32,24 +32,14 @@* @fmt: Pointer to format string */ #define DPU_DEBUG (fmt, ...) \ - do { \ - if (drm_debug_enabled(DRM_UT_KMS)) \ - DRM_DEBUG(fmt, ##__VA_ARGS__); \ - else \ - pr_debug(fmt, ##__VA_ARGS__); \ - } while (0) + DRM_DEBUG_DRIVER(fmt, ##__VA_ARGS__)/** * DPU_DEBUG_DRIVER - macro for hardware driver logging * @fmt: Pointer to format string */ #define DPU_DEBUG_DRIVER (fmt, ...) \ - do { \ - if (drm_debug_enabled(DRM_UT_DRIVER)) \ - DRM_ERROR(fmt, ##__VA_ARGS__); \ - else \ - pr_debug(fmt, ##__VA_ARGS__); \ - } while (0) + DRM_DEBUG_DRIVER(fmt, ##__VA_ARGS__)#define DPU_ERROR (fmt, ...) pr_err("[dpu error]" fmt, ##__VA_ARGS__)#define DPU_ERROR_RATELIMITED (fmt, ...) pr_err_ratelimited("[dpu error]" fmt, ##__VA_ARGS__)
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 156/215 drm/msm/dp: reset the link phy params before link training
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Abhinav Kumar <[email protected]>
[ Upstream commit 319aca883bfa1b85ee08411541b51b9a934ac858 ]
Before re-starting link training reset the link phy params namely the pre-emphasis and voltage swing levels otherwise the next link training begins at the previously cached levels which can result in link training failures.
Patchwork: https://patchwork.freedesktop.org/patch/605946/
--- drivers/gpu/drm/msm/dp/dp_ctrl.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/gpu/drm/msm/dp/dp_ctrl.c +2 -0
@@ -1237,6 +1237,8 @@ static int dp_ctrl_link_train(struct dp_ctrl_private *ctrl, link_info.rate = ctrl->link->link_params.rate; link_info.capabilities =DP_LINK_CAP_ENHANCED_FRAMING ; +dp_link_reset_phy_params_vx_px (ctrl->link); +dp_aux_link_configure (ctrl->aux, &link_info);drm_dp_dpcd_write (ctrl->aux,DP_MAIN_LINK_CHANNEL_CODING_SET , &encoding,1 );
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 157/215 drm/msm/dpu: cleanup FB if dpu_format_populate_layout fails
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dmitry Baryshkov <[email protected]>
[ Upstream commit bfa1a6283be390947d3649c482e5167186a37016 ]
If the dpu_format_populate_layout() fails, then FB is prepared, but not cleaned up. This ends up leaking the pin_count on the GEM object and causes a splat during DRM file closure:
msm_obj->pin_count
WARNING: CPU: 2 PID: 569 at drivers/gpu/drm/msm/msm_gem.c:121 update_lru_locked+0xc4/0xcc [...] Call trace: update_lru_locked+0xc4/0xcc put_pages+0xac/0x100 msm_gem_free_object+0x138/0x180 drm_gem_object_free+0x1c/0x30 drm_gem_object_handle_put_unlocked+0x108/0x10c drm_gem_object_release_handle+0x58/0x70 idr_for_each+0x68/0xec drm_gem_release+0x28/0x40 drm_file_free+0x174/0x234 drm_release+0xb0/0x160 __fput+0xc0/0x2c8 __fput_sync+0x50/0x5c __arm64_sys_close+0x38/0x7c invoke_syscall+0x48/0x118 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x4c/0x120 el0t_64_sync_handler+0x100/0x12c el0t_64_sync+0x190/0x194 irq event stamp: 129818 hardirqs last enabled at (129817): [<ffffa5f6d953fcc0>] console_unlock+0x118/0x124 hardirqs last disabled at (129818): [<ffffa5f6da7dcf04>] el1_dbg+0x24/0x8c softirqs last enabled at (129808): [<ffffa5f6d94afc18>] handle_softirqs+0x4c8/0x4e8 softirqs last disabled at (129785): [<ffffa5f6d94105e4>] __do_softirq+0x14/0x20
Patchwork: https://patchwork.freedesktop.org/patch/600714/
--- drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c +3 -0
@@ -906,6 +906,9 @@ static int dpu_plane_prepare_fb(struct drm_plane *plane, new_state->fb, &layout);if (ret) {DPU_ERROR_PLANE (pdpu,"failed to get format layout, %d\n" , ret); +if (pstate->aspace) +msm_framebuffer_cleanup (new_state->fb, pstate->aspace, + pstate->needs_dirtyfb);return ret; }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 158/215 mmc: mmc_test: Fix NULL dereference on allocation failure
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
[ Upstream commit a1e627af32ed60713941cbfc8075d44cad07f6dd ]
If the "test->highmem = alloc_pages()" allocation fails then calling __free_pages(test->highmem) will result in a NULL dereference. Also change the error code to -ENOMEM instead of returning success.
--- drivers/mmc/core/mmc_test.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
drivers/mmc/core/mmc_test.c +5 -4
@@ -3111,13 +3111,13 @@ static ssize_t mtf_test_write(struct file *file, const char __user *buf, test->buffer =kzalloc (BUFFER_SIZE ,GFP_KERNEL );#ifdef CONFIG_HIGHMEM test->highmem =alloc_pages (GFP_KERNEL | __GFP_HIGHMEM,BUFFER_ORDER ); +if (!test->highmem) { + count = -ENOMEM ; + goto free_test_buffer; + }#endif -#ifdef CONFIG_HIGHMEM -if (test->buffer && test->highmem) { -#else if (test->buffer) { -#endif mutex_lock (&mmc_test_lock);mmc_test_run (test, testcase);mutex_unlock (&mmc_test_lock);
@@ -3125,6 +3125,7 @@ static ssize_t mtf_test_write(struct file *file, const char __user *buf,#ifdef CONFIG_HIGHMEM __free_pages (test->highmem,BUFFER_ORDER ); +free_test_buffer:#endif kfree (test->buffer);kfree (test);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 159/215 Bluetooth: MGMT: Add error handling to pair_device()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Griffin Kroah-Hartman <[email protected]>
commit 538fd3921afac97158d4177139a0ad39f056dbb2 upstream.
hci_conn_params_add() never checks for a NULL value and could lead to a NULL pointer dereference causing a crash.
Fixed by adding error handling in the function.
--- net/bluetooth/mgmt.c | 4 ++++ 1 file changed, 4 insertions(+)
net/bluetooth/mgmt.c +4 -0
@@ -2967,6 +2967,10 @@ static int pair_device(struct sock *sk,* will be kept and this function does nothing. */ p =hci_conn_params_add (hdev, &cp->addr.bdaddr, addr_type); +if (!p) { + err = -EIO ; + goto unlock; + }if (p->auto_connect ==HCI_AUTO_CONN_EXPLICIT ) p->auto_connect =HCI_AUTO_CONN_DISABLED ;
Greg Kroah-Hartman
maintainerPATCH 160/215 scsi: core: Fix the return value of scsi_logical_block_count()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chaotian Jing <[email protected]>
commit f03e94f23b04c2b71c0044c1534921b3975ef10c upstream.
scsi_logical_block_count() should return the block count of a given SCSI command. The original implementation ended up shifting twice, leading to an incorrect count being returned. Fix the conversion between bytes and logical blocks.
--- include/scsi/scsi_cmnd.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/scsi/scsi_cmnd.h +1 -1
@@ -247,7 +247,7 @@ static inline sector_t scsi_get_lba(strustatic inline unsigned int scsi_logical_block_count (struct scsi_cmnd *scmd) { -unsigned int shift =ilog2 (scmd->device->sector_size) -SECTOR_SHIFT ; +unsigned int shift =ilog2 (scmd->device->sector_size);return blk_rq_bytes (scsi_cmd_to_rq (scmd)) >> shift; }
Greg Kroah-Hartman
maintainerPATCH 161/215 MIPS: Loongson64: Set timer mode in cpu-probe
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiaxun Yang <[email protected]>
commit 1cb6ab446424649f03c82334634360c2e3043684 upstream.
Loongson64 C and G processors have EXTIMER feature which is conflicting with CP0 counter.
Although the processor resets in EXTIMER disabled & INTIMER enabled mode, which is compatible with MIPS CP0 compare, firmware may attempt to enable EXTIMER and interfere CP0 compare.
Set timer mode back to MIPS compatible mode to fix booting on systems with such firmware before we have an actual driver for EXTIMER.
--- arch/mips/kernel/cpu-probe.c | 4 ++++ 1 file changed, 4 insertions(+)
arch/mips/kernel/cpu-probe.c +4 -0
@@ -1782,12 +1782,16 @@ static inline void cpu_probe_loongson(st c->ases |= (MIPS_ASE_LOONGSON_MMI |MIPS_ASE_LOONGSON_CAM |MIPS_ASE_LOONGSON_EXT |MIPS_ASE_LOONGSON_EXT2 ); c->ases &= ~MIPS_ASE_VZ ;/* VZ of Loongson-3A2000/3000 is incomplete */ +change_c0_config6 (LOONGSON_CONF6_EXTIMER |LOONGSON_CONF6_INTIMER , +LOONGSON_CONF6_INTIMER );break ;case PRID_IMP_LOONGSON_64G : __cpu_name[cpu] ="ICT Loongson-3" ;set_elf_platform (cpu,"loongson3a" );set_isa (c,MIPS_CPU_ISA_M64R2 );decode_cpucfg (c); +change_c0_config6 (LOONGSON_CONF6_EXTIMER |LOONGSON_CONF6_INTIMER , +LOONGSON_CONF6_INTIMER );break ;default :panic ("Unknown Loongson Processor ID!" );
Greg Kroah-Hartman
maintainerPATCH 162/215 HID: wacom: Defer calculation of resolution until resolution_code is known
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jason Gerecke <[email protected]>
commit 1b8f9c1fb464968a5b18d3acc1da8c00bad24fad upstream.
The Wacom driver maps the HID_DG_TWIST usage to ABS_Z (rather than ABS_RZ) for historic reasons. When the code to support twist was introduced in commit 50066a042da5 ("HID: wacom: generic: Add support for height, tilt, and twist usages"), we were careful to write it in such a way that it had HID calculate the resolution of the twist axis assuming ABS_RZ instead (so that we would get correct angular behavior). This was broken with the introduction of commit 08a46b4190d3 ("HID: wacom: Set a default resolution for older tablets"), which moved the resolution calculation to occur *before* the adjustment from ABS_Z to ABS_RZ occurred.
This commit moves the calculation of resolution after the point that we are finished setting things up for its proper use.
--- drivers/hid/wacom_wac.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/hid/wacom_wac.c +3 -1
@@ -1924,12 +1924,14 @@ static void wacom_map_usage(struct inputint fmax = field->logical_maximum;unsigned int equivalent_usage =wacom_equivalent_usage (usage->hid);int resolution_code = code; -int resolution =hidinput_calc_abs_res (field, resolution_code); +int resolution;if (equivalent_usage ==HID_DG_TWIST ) { resolution_code =ABS_RZ ; } + resolution =hidinput_calc_abs_res (field, resolution_code); +if (equivalent_usage ==HID_GD_X ) { fmin += features->offset_left; fmax -= features->offset_right;
Greg Kroah-Hartman
maintainerPATCH 163/215 HID: microsoft: Add rumble support to latest xbox controllers
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Siarhei Vishniakou <[email protected]>
commit f5554725f30475b05b5178b998366f11ecb50c7f upstream.
Currently, rumble is only supported via bluetooth on a single xbox controller, called 'model 1708'. On the back of the device, it's named 'wireless controller for xbox one'. However, in 2021, Microsoft released a firmware update for this controller. As part of this update, the HID descriptor of the device changed. The product ID was also changed from 0x02fd to 0x0b20. On this controller, rumble was supported via hid-microsoft, which matched against the old product id (0x02fd). As a result, the firmware update broke rumble support on this controller.
The hid-microsoft driver actually supports rumble on the new firmware, as well. So simply adding new product id is sufficient to bring back this support.
After discussing further with the xbox team, it was pointed out that another xbox controller, xbox elite series 2, can be supported in a similar way.
Add rumble support for all of these devices in this patch. Two of the devices have received firmware updates that caused their product id's to change. Both old and new firmware versions of these devices were tested.
The tested controllers are:
1. 'wireless controller for xbox one', model 1708
2. 'xbox wireless controller', model 1914. This is also sometimes referred to as 'xbox series S|X'.
3. 'elite series 2', model 1797.
The tested configurations are:
1. model 1708, pid 0x02fd (old firmware)
2. model 1708, pid 0x0b20 (new firmware)
3. model 1914, pid 0x0b13
4. model 1797, pid 0x0b05 (old firmware)
5. model 1797, pid 0x0b22 (new firmware)
I verified rumble support on both bluetooth and usb.
--- drivers/hid/hid-ids.h | 10 +++++++++- drivers/hid/hid-microsoft.c | 11 ++++++++++- 2 files changed, 19 insertions(+), 2 deletions(-)
drivers/hid/hid-ids.h +9 -1
@@ -894,7 +894,15 @@#define USB_DEVICE_ID_MS_TYPE_COVER_2 0x07a9#define USB_DEVICE_ID_MS_POWER_COVER 0x07da#define USB_DEVICE_ID_MS_SURFACE3_COVER 0x07de -#define USB_DEVICE_ID_MS_XBOX_ONE_S_CONTROLLER 0x02fd +/* +* For a description of the Xbox controller models, refer to: +* https://en.wikipedia.org/wiki/Xbox_Wireless_Controller#Summary +*/ +#define USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1708 0x02fd +#define USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1708_BLE 0x0b20 +#define USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1914 0x0b13 +#define USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1797 0x0b05 +#define USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1797_BLE 0x0b22#define USB_DEVICE_ID_MS_PIXART_MOUSE 0x00cb#define USB_DEVICE_ID_8BITDO_SN30_PRO_PLUS 0x02e0#define USB_DEVICE_ID_MS_MOUSE_0783 0x0783
drivers/hid/hid-microsoft.c +10 -1
@@ -446,7 +446,16 @@ static const struct hid_device_id ms_dev .driver_data = MS_PRESENTER }, { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, 0x091B), .driver_data = MS_SURFACE_DIAL }, - { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_XBOX_ONE_S_CONTROLLER), + + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1708), + .driver_data = MS_QUIRK_FF }, + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1708_BLE), + .driver_data = MS_QUIRK_FF }, + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1914), + .driver_data = MS_QUIRK_FF }, + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1797), + .driver_data = MS_QUIRK_FF }, + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_XBOX_CONTROLLER_MODEL_1797_BLE), .driver_data = MS_QUIRK_FF }, { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_8BITDO_SN30_PRO_PLUS), .driver_data = MS_QUIRK_FF },
Greg Kroah-Hartman
maintainerPATCH 164/215 cxgb4: add forgotten u64 ivlan cast before shift
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nikolay Kuratov <[email protected]>
commit 80a1e7b83bb1834b5568a3872e64c05795d88f31 upstream.
It is done everywhere in cxgb4 code, e.g. in is_filter_exact_match() There is no reason it should not be done here
Found by Linux Verification Center (linuxtesting.org) with SVACE
--- drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c +2 -1
@@ -1244,7 +1244,8 @@ static u64 hash_filter_ntuple(struct ch_* in the Compressed Filter Tuple. */ if (tp->vlan_shift >=0 && fs->mask.ivlan) - ntuple |= (FT_VLAN_VLD_F | fs->val.ivlan) << tp->vlan_shift; + ntuple |= (u64)(FT_VLAN_VLD_F | + fs->val.ivlan) << tp->vlan_shift;if (tp->port_shift >=0 && fs->mask.iport) ntuple |= (u64 )fs->val.iport << tp->port_shift;
Greg Kroah-Hartman
maintainerPATCH 165/215 KVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marc Zyngier <[email protected]>
commit 3e6245ebe7ef341639e9a7e402b3ade8ad45a19f upstream.
On a system with a GICv3, if a guest hasn't been configured with GICv3 and that the host is not capable of GICv2 emulation, a write to any of the ICC_*SGI*_EL1 registers is trapped to EL2.
We therefore try to emulate the SGI access, only to hit a NULL pointer as no private interrupt is allocated (no GIC, remember?).
The obvious fix is to give the guest what it deserves, in the shape of a UNDEF exception.
--- arch/arm64/kvm/sys_regs.c | 6 ++++++ arch/arm64/kvm/vgic/vgic.h | 7 +++++++ 2 files changed, 13 insertions(+)
arch/arm64/kvm/sys_regs.c +6 -0
@@ -30,6 +30,7 @@#include <trace/events/kvm.h> #include "sys_regs.h" +#include "vgic/vgic.h" #include "trace.h"
@@ -203,6 +204,11 @@ static bool access_gic_sgi(struct kvm_vc {bool g1; +if (!kvm_has_gicv3 (vcpu->kvm)) { +kvm_inject_undefined (vcpu); +return false; + } +if (!p->is_write)return read_from_write_only (vcpu, p, r);
arch/arm64/kvm/vgic/vgic.h +7 -0
@@ -324,4 +324,11 @@ void vgic_v4_configure_vsgis(struct kvmvoid vgic_v4_get_vlpi_state (struct vgic_irq *irq,bool *val);int vgic_v4_request_vpe_irq (struct kvm_vcpu *vcpu,int irq); +static inline bool kvm_has_gicv3 (struct kvm *kvm) +{ +return (static_branch_unlikely (&kvm_vgic_global_state.gicv3_cpuif) && +irqchip_in_kernel (kvm) && + kvm->arch.vgic.vgic_model ==KVM_DEV_TYPE_ARM_VGIC_V3 ); +} +#endif
Greg Kroah-Hartman
maintainerPATCH 166/215 mmc: dw_mmc: allow biu and ciu clocks to defer
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ben Whitten <[email protected]>
commit 6275c7bc8dd07644ea8142a1773d826800f0f3f7 upstream.
Fix a race condition if the clock provider comes up after mmc is probed, this causes mmc to fail without retrying.
When given the DEFER error from the clk source, pass it on up the chain.
--- drivers/mmc/host/dw_mmc.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/mmc/host/dw_mmc.c +8 -0
@@ -3246,6 +3246,10 @@ int dw_mci_probe(struct dw_mci *host) host->biu_clk =devm_clk_get (host->dev,"biu" );if (IS_ERR (host->biu_clk)) {dev_dbg (host->dev,"biu clock not available\n" ); + ret =PTR_ERR (host->biu_clk); +if (ret == -EPROBE_DEFER ) +return ret; + }else { ret =clk_prepare_enable (host->biu_clk);if (ret) {
@@ -3257,6 +3261,10 @@ int dw_mci_probe(struct dw_mci *host) host->ciu_clk =devm_clk_get (host->dev,"ciu" );if (IS_ERR (host->ciu_clk)) {dev_dbg (host->dev,"ciu clock not available\n" ); + ret =PTR_ERR (host->ciu_clk); +if (ret == -EPROBE_DEFER ) + goto err_clk_biu; + host->bus_hz = host->pdata->bus_hz; }else { ret =clk_prepare_enable (host->ciu_clk);
Greg Kroah-Hartman
maintainerPATCH 167/215 Revert "drm/amd/display: Validate hw_points_num before using it"
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Hung <[email protected]>
commit 8f4bdbc8e99db6ec9cb0520748e49a2f2d7d1727 upstream.
This reverts commit 58c3b3341cea4f75dc8c003b89f8a6dd8ec55e50.
[WHY & HOW]
The writeback series cause a regression in thunderbolt display.
--- drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dwb_cm.c | 3 --- 1 file changed, 3 deletions(-)
drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dwb_cm.c +0 -3
@@ -243,9 +243,6 @@ static bool dwb3_program_ogam_lut(return false; } -if (params->hw_points_num ==0 ) -return false; -REG_SET (DWB_OGAM_CONTROL ,0 ,DWB_OGAM_MODE ,2 ); current_mode =dwb3_get_ogam_current (dwbc30);
Greg Kroah-Hartman
maintainerPATCH 168/215 hwmon: (ltc2992) Fix memory leak in ltc2992_parse_dt()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Javier Carrasco <[email protected]>
commit a94ff8e50c20bde6d50864849a98b106e45d30c6 upstream.
A new error path was added to the fwnode_for_each_available_node() loop in ltc2992_parse_dt(), which leads to an early return that requires a call to fwnode_handle_put() to avoid a memory leak in that case.
Add the missing fwnode_handle_put() in the error path from a zero value shunt resistor.
--- drivers/hwmon/ltc2992.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/hwmon/ltc2992.c +3 -1
@@ -913,9 +913,11 @@ static int ltc2992_parse_dt(struct ltc29 ret =fwnode_property_read_u32 (child,"shunt-resistor-micro-ohms" , &val);if (!ret) { -if (!val) +if (!val) { +fwnode_handle_put (child);return dev_err_probe (&st->client->dev, -EINVAL ,"shunt resistor value cannot be zero\n" ); + } st->r_sense_uohm[addr] = val; } }
Greg Kroah-Hartman
maintainerPATCH 169/215 ALSA: timer: Relax start tick time check for slave timer elements
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit ccbfcac05866ebe6eb3bc6d07b51d4ed4fcde436 upstream.
The recent addition of a sanity check for a too low start tick time seems breaking some applications that uses aloop with a certain slave timer setup. They may have the initial resolution 0, hence it's treated as if it were a too low value.
Relax and skip the check for the slave timer instance for addressing the regression.
--- sound/core/timer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sound/core/timer.c +1 -1
@@ -556,7 +556,7 @@ static int snd_timer_start1(struct snd_t/* check the actual time for the start tick; * bail out as error if it's way too low (< 100us) */ -if (start) { +if (start && !(timer->hw.flags &SNDRV_TIMER_HW_SLAVE )) {if ((u64 )snd_timer_hw_resolution (timer) * ticks <100000 ) { result = -EINVAL ; goto unlock;
Greg Kroah-Hartman
maintainerPATCH 170/215 mm/numa: no task_numa_fault() call if PMD is changed
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zi Yan <[email protected]>
commit fd8c35a92910f4829b7c99841f39b1b952c259d5 upstream.
When handling a numa page fault, task_numa_fault() should be called by a process that restores the page table of the faulted folio to avoid duplicated stats counting. Commit c5b5a3dd2c1f ("mm: thp: refactor NUMA fault handling") restructured do_huge_pmd_numa_page() and did not avoid task_numa_fault() call in the second page table check after a numa migration failure. Fix it by making all !pmd_same() return immediately.
This issue can cause task_numa_fault() being called more than necessary and lead to unexpected numa balancing results (It is hard to tell whether the issue will cause positive or negative performance impact due to duplicated numa fault counting).
--- mm/huge_memory.c | 30 +++++++++++++----------------- 1 file changed, 13 insertions(+), 17 deletions(-)
mm/huge_memory.c +13 -17
@@ -1437,7 +1437,7 @@ vm_fault_t do_huge_pmd_numa_page(struct vmf->ptl =pmd_lock (vma->vm_mm, vmf->pmd);if (unlikely (!pmd_same (oldpmd, *vmf->pmd))) {spin_unlock (vmf->ptl); - goto out; +return 0 ; } pmd =pmd_modify (oldpmd, vma->vm_page_prot);
@@ -1465,23 +1465,16 @@ vm_fault_t do_huge_pmd_numa_page(structif (migrated) { flags |=TNF_MIGRATED ; page_nid = target_nid; - }else { - flags |=TNF_MIGRATE_FAIL ; - vmf->ptl =pmd_lock (vma->vm_mm, vmf->pmd); -if (unlikely (!pmd_same (oldpmd, *vmf->pmd))) { -spin_unlock (vmf->ptl); - goto out; - } - goto out_map; +task_numa_fault (last_cpupid, page_nid,HPAGE_PMD_NR , flags); +return 0 ; } -out: -if (page_nid !=NUMA_NO_NODE ) -task_numa_fault (last_cpupid, page_nid,HPAGE_PMD_NR , - flags); - -return 0 ; - + flags |=TNF_MIGRATE_FAIL ; + vmf->ptl =pmd_lock (vma->vm_mm, vmf->pmd); +if (unlikely (!pmd_same (oldpmd, *vmf->pmd))) { +spin_unlock (vmf->ptl); +return 0 ; + } out_map:/* Restore the PMD */ pmd =pmd_modify (oldpmd, vma->vm_page_prot);
@@ -1491,7 +1484,10 @@ out_map:set_pmd_at (vma->vm_mm, haddr, vmf->pmd, pmd);update_mmu_cache_pmd (vma, vmf->address, vmf->pmd);spin_unlock (vmf->ptl); - goto out; + +if (page_nid !=NUMA_NO_NODE ) +task_numa_fault (last_cpupid, page_nid,HPAGE_PMD_NR , flags); +return 0 ; }/*
Greg Kroah-Hartman
maintainerPATCH 171/215 mm/numa: no task_numa_fault() call if PTE is changed
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zi Yan <[email protected]>
commit 40b760cfd44566bca791c80e0720d70d75382b84 upstream.
When handling a numa page fault, task_numa_fault() should be called by a process that restores the page table of the faulted folio to avoid duplicated stats counting. Commit b99a342d4f11 ("NUMA balancing: reduce TLB flush via delaying mapping on hint page fault") restructured do_numa_page() and did not avoid task_numa_fault() call in the second page table check after a numa migration failure. Fix it by making all !pte_same() return immediately.
This issue can cause task_numa_fault() being called more than necessary and lead to unexpected numa balancing results (It is hard to tell whether the issue will cause positive or negative performance impact due to duplicated numa fault counting).
--- mm/memory.c | 29 ++++++++++++++--------------- 1 file changed, 14 insertions(+), 15 deletions(-)
mm/memory.c +14 -15
@@ -4407,7 +4407,7 @@ static vm_fault_t do_numa_page(struct vmspin_lock (vmf->ptl);if (unlikely (!pte_same (*vmf->pte, vmf->orig_pte))) {pte_unmap_unlock (vmf->pte, vmf->ptl); - goto out; +return 0 ; }/* Get the normal PTE */
@@ -4454,21 +4454,17 @@ static vm_fault_t do_numa_page(struct vmif (migrate_misplaced_page (page, vma, target_nid)) { page_nid = target_nid; flags |=TNF_MIGRATED ; - }else { - flags |=TNF_MIGRATE_FAIL ; - vmf->pte =pte_offset_map (vmf->pmd, vmf->address); -spin_lock (vmf->ptl); -if (unlikely (!pte_same (*vmf->pte, vmf->orig_pte))) { -pte_unmap_unlock (vmf->pte, vmf->ptl); - goto out; - } - goto out_map; +task_numa_fault (last_cpupid, page_nid,1 , flags); +return 0 ; } -out: -if (page_nid !=NUMA_NO_NODE ) -task_numa_fault (last_cpupid, page_nid,1 , flags); -return 0 ; + flags |=TNF_MIGRATE_FAIL ; + vmf->pte =pte_offset_map (vmf->pmd, vmf->address); +spin_lock (vmf->ptl); +if (unlikely (!pte_same (*vmf->pte, vmf->orig_pte))) { +pte_unmap_unlock (vmf->pte, vmf->ptl); +return 0 ; + } out_map:/* * Make it present again, depending on how arch implements
@@ -4482,7 +4478,10 @@ out_map:ptep_modify_prot_commit (vma, vmf->address, vmf->pte, old_pte, pte);update_mmu_cache (vma, vmf->address, vmf->pte);pte_unmap_unlock (vmf->pte, vmf->ptl); - goto out; + +if (page_nid !=NUMA_NO_NODE ) +task_numa_fault (last_cpupid, page_nid,1 , flags); +return 0 ; }static inline vm_fault_t create_huge_pmd (struct vm_fault *vmf)
Greg Kroah-Hartman
maintainerPATCH 172/215 Bluetooth: hci_ldisc: check HCI_UART_PROTO_READY flag in HCIUARTGETPROTO
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lee, Chun-Yi <[email protected]>
commit 9c33663af9ad115f90c076a1828129a3fbadea98 upstream.
This patch adds code to check HCI_UART_PROTO_READY flag before accessing hci_uart->proto. It fixes the race condition in hci_uart_tty_ioctl() between HCIUARTSETPROTO and HCIUARTGETPROTO. This issue bug found by Yu Hao and Weiteng Chen:
BUG: general protection fault in hci_uart_tty_ioctl [1]
The information of C reproducer can also reference the link [2]
--- drivers/bluetooth/hci_ldisc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/bluetooth/hci_ldisc.c +2 -1
@@ -768,7 +768,8 @@ static int hci_uart_tty_ioctl(struct ttybreak ;case HCIUARTGETPROTO : -if (test_bit (HCI_UART_PROTO_SET , &hu->flags)) +if (test_bit (HCI_UART_PROTO_SET , &hu->flags) && +test_bit (HCI_UART_PROTO_READY , &hu->flags)) err = hu->proto->id;else err = -EUNATCH ;
Greg Kroah-Hartman
maintainerPATCH 173/215 Input: MT - limit max slots
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tetsuo Handa <[email protected]>
commit 99d3bf5f7377d42f8be60a6b9cb60fb0be34dceb upstream.
syzbot is reporting too large allocation at input_mt_init_slots(), for num_slots is supplied from userspace using ioctl(UI_DEV_CREATE).
Since nobody knows possible max slots, this patch chose 1024.
--- drivers/input/input-mt.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/input/input-mt.c +3 -0
@@ -45,6 +45,9 @@ int input_mt_init_slots(struct input_devreturn 0 ;if (mt)return mt->num_slots != num_slots ? -EINVAL :0 ; +/* Arbitrary limit for avoiding too large memory allocation. */ +if (num_slots >1024 ) +return -EINVAL ; mt =kzalloc (struct_size (mt, slots, num_slots),GFP_KERNEL );if (!mt)
Greg Kroah-Hartman
maintainerPATCH 174/215 tools: move alignment-related macros to new <linux/align.h>
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Lobakin <[email protected]>
commit 10a04ff09bcc39e0044190ffe9f00f998f13647c upstream.
Currently, tools have *ALIGN*() macros scattered across the unrelated headers, as there are only 3 of them and they were added separately each time on an as-needed basis.
Anyway, let's make it more consistent with the kernel headers and allow using those macros outside of the mentioned headers. Create <linux/align.h> inside the tools/ folder and include it where needed.
--- tools/include/linux/align.h | 12 ++++++++++++ tools/include/linux/bitmap.h | 2 +- 2 files changed, 13 insertions(+), 1 deletion(-) create mode 100644 tools/include/linux/align.h
tools/include/linux/align.h new file +12 -0
@@ -0,0 +1,12 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#ifndef _TOOLS_LINUX_ALIGN_H +#define _TOOLS_LINUX_ALIGN_H + +#include <uapi/linux/const.h> + +#define ALIGN (x, a) __ALIGN_KERNEL((x), (a)) +#define ALIGN_DOWN (x, a) __ALIGN_KERNEL((x) - ((a) - 1), (a)) +#define IS_ALIGNED (x, a) (((x) & ((typeof(x))(a) - 1)) == 0) + +#endif /* _TOOLS_LINUX_ALIGN_H */
tools/include/linux/bitmap.h +1 -1
@@ -3,6 +3,7 @@#define _PERF_BITOPS_H#include <string.h> +#include <linux/align.h> #include <linux/bitops.h> #include <stdlib.h> #include <linux/kernel.h>
@@ -160,7 +161,6 @@ static inline int bitmap_and(unsigned lo#define BITMAP_MEM_ALIGNMENT (8 * sizeof(unsigned long))#endif #define BITMAP_MEM_MASK (BITMAP_MEM_ALIGNMENT - 1) -#define IS_ALIGNED (x, a) (((x) & ((typeof(x))(a) - 1)) == 0)static inline int bitmap_equal (const unsigned long *src1,const unsigned long *src2,unsigned int nbits)
Greg Kroah-Hartman
maintainerPATCH 175/215 drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jesse Zhang <[email protected]>
commit 88a9a467c548d0b3c7761b4fd54a68e70f9c0944 upstream.
Initialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001.
V2: To really improve the handling we would actually
need to have a separate value of 0xffffffff.(Christian)
--- drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c +2 -1
@@ -733,7 +733,8 @@ int amdgpu_vce_ring_parse_cs(struct amdguint32_t created =0 ;uint32_t allocated =0 ;uint32_t tmp, handle =0 ; -uint32_t *size = &tmp; +uint32_t dummy =0xffffffff ; +uint32_t *size = &dummy;unsigned idx;int i, r =0 ;
Greg Kroah-Hartman
maintainerPATCH 176/215 btrfs: run delayed iputs when flushing delalloc
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Josef Bacik <[email protected]>
commit 2d3447261031503b181dacc549fe65ffe2d93d65 upstream.
We have transient failures with btrfs/301, specifically in the part where we do
for i in $(seq 0 10); do
write 50m to file
rm -f file
done
Sometimes this will result in a transient quota error, and it's because sometimes we start writeback on the file which results in a delayed iput, and thus the rm doesn't actually clean the file up. When we're flushing the quota space we need to run the delayed iputs to make sure all the unlinks that we think have completed have actually completed. This removes the small window where we could fail to find enough space in our quota.
--- fs/btrfs/qgroup.c | 2 ++ 1 file changed, 2 insertions(+)
fs/btrfs/qgroup.c +2 -0
@@ -3677,6 +3677,8 @@ static int try_flush_qgroup(struct btrfsreturn 0 ; } +btrfs_run_delayed_iputs (root->fs_info); +btrfs_wait_on_delayed_iputs (root->fs_info); ret =btrfs_start_delalloc_snapshot (root, true);if (ret <0 ) goto out;
Greg Kroah-Hartman
maintainerPATCH 177/215 pinctrl: rockchip: correct RK3328 iomux width flag for GPIO2-B pins
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huang-Huang Bao <[email protected]>
commit 128f71fe014fc91efa1407ce549f94a9a9f1072c upstream.
The base iomux offsets for each GPIO pin line are accumulatively calculated based off iomux width flag in rockchip_pinctrl_get_soc_data. If the iomux width flag is one of IOMUX_WIDTH_4BIT, IOMUX_WIDTH_3BIT or IOMUX_WIDTH_2BIT, the base offset for next pin line would increase by 8 bytes, otherwise it would increase by 4 bytes.
Despite most of GPIO2-B iomux have 2-bit data width, which can be fit into 4 bytes space with write mask, it actually take 8 bytes width for whole GPIO2-B line.
Commit e8448a6c817c ("pinctrl: rockchip: fix pinmux bits for RK3328 GPIO2-B pins") wrongly set iomux width flag to 0, causing all base iomux offset for line after GPIO2-B to be calculated wrong. Fix the iomux width flag to IOMUX_WIDTH_2BIT so the offset after GPIO2-B is correctly increased by 8, matching the actual width of GPIO2-B iomux.
--- drivers/pinctrl/pinctrl-rockchip.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/pinctrl/pinctrl-rockchip.c +1 -1
@@ -3218,7 +3218,7 @@ static struct rockchip_pin_bank rk3328_pPIN_BANK_IOMUX_FLAGS (0 ,32 ,"gpio0" ,0 ,0 ,0 ,0 ),PIN_BANK_IOMUX_FLAGS (1 ,32 ,"gpio1" ,0 ,0 ,0 ,0 ),PIN_BANK_IOMUX_FLAGS (2 ,32 ,"gpio2" ,0 , -0 , +IOMUX_WIDTH_2BIT ,IOMUX_WIDTH_3BIT ,0 ), PIN_BANK_IOMUX_FLAGS(3, 32, "gpio3",
Greg Kroah-Hartman
maintainerPATCH 178/215 pinctrl: single: fix potential NULL dereference in pcs_get_function()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ma Ke <[email protected]>
commit 1c38a62f15e595346a1106025722869e87ffe044 upstream.
pinmux_generic_get_function() can return NULL and the pointer 'function' was dereferenced without checking against NULL. Add checking of pointer 'function' in pcs_get_function().
Found by code review.
--- drivers/pinctrl/pinctrl-single.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/pinctrl/pinctrl-single.c +2 -0
@@ -350,6 +350,8 @@ static int pcs_get_function(struct pinctreturn -ENOTSUPP ; fselector = setting->func; function =pinmux_generic_get_function (pctldev, fselector); +if (!function) +return -EINVAL ; *func = function->data;if (!(*func)) { dev_err(pcs->dev, "%s could not find function%i\n",
Greg Kroah-Hartman
maintainerPATCH 179/215 wifi: mwifiex: duplicate static structs used in driver instances
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sascha Hauer <[email protected]>
commit 27ec3c57fcadb43c79ed05b2ea31bc18c72d798a upstream.
mwifiex_band_2ghz and mwifiex_band_5ghz are statically allocated, but used and modified in driver instances. Duplicate them before using them in driver instances so that different driver instances do not influence each other.
This was observed on a board which has one PCIe and one SDIO mwifiex adapter. It blew up in mwifiex_setup_ht_caps(). This was called with the statically allocated struct which is modified in this function.
--- drivers/net/wireless/marvell/mwifiex/cfg80211.c | 32 +++++++++++++++++++----- 1 file changed, 26 insertions(+), 6 deletions(-)
drivers/net/wireless/marvell/mwifiex/cfg80211.c +26 -6
@@ -4328,11 +4328,27 @@ int mwifiex_register_cfg80211(struct mwiif (ISSUPP_ADHOC_ENABLED (adapter->fw_cap_info)) wiphy->interface_modes |=BIT (NL80211_IFTYPE_ADHOC ); - wiphy->bands[NL80211_BAND_2GHZ ] = &mwifiex_band_2ghz; -if (adapter->config_bands &BAND_A ) - wiphy->bands[NL80211_BAND_5GHZ ] = &mwifiex_band_5ghz; -else + wiphy->bands[NL80211_BAND_2GHZ ] =devm_kmemdup (adapter->dev, + &mwifiex_band_2ghz, +sizeof (mwifiex_band_2ghz), +GFP_KERNEL ); +if (!wiphy->bands[NL80211_BAND_2GHZ ]) { + ret = -ENOMEM ; + goto err; + } + +if (adapter->config_bands &BAND_A ) { + wiphy->bands[NL80211_BAND_5GHZ ] =devm_kmemdup (adapter->dev, + &mwifiex_band_5ghz, +sizeof (mwifiex_band_5ghz), +GFP_KERNEL ); +if (!wiphy->bands[NL80211_BAND_5GHZ ]) { + ret = -ENOMEM ; + goto err; + } + }else { wiphy->bands[NL80211_BAND_5GHZ ] =NULL ; + }if (adapter->drcs_enabled &&ISSUPP_DRCS_ENABLED (adapter->fw_cap_info)) wiphy->iface_combinations = &mwifiex_iface_comb_ap_sta_drcs;
@@ -4425,8 +4441,7 @@ int mwifiex_register_cfg80211(struct mwiif (ret <0 ) {mwifiex_dbg (adapter,ERROR ,"%s: wiphy_register failed: %d\n" , __func__, ret); -wiphy_free (wiphy); -return ret; + goto err; }if (!adapter->regd) {
@@ -4468,4 +4483,9 @@ int mwifiex_register_cfg80211(struct mwi adapter->wiphy = wiphy;return ret; + +err: +wiphy_free (wiphy); + +return ret; }
Greg Kroah-Hartman
maintainerPATCH 180/215 net: mana: Fix race of mana_hwc_post_rx_wqe and new hwc response
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Haiyang Zhang <[email protected]>
commit 8af174ea863c72f25ce31cee3baad8a301c0cf0f upstream.
The mana_hwc_rx_event_handler() / mana_hwc_handle_resp() calls complete(&ctx->comp_event) before posting the wqe back. It's possible that other callers, like mana_create_txq(), start the next round of mana_hwc_send_request() before the posting of wqe. And if the HW is fast enough to respond, it can hit no_wqe error on the HW channel, then the response message is lost. The mana driver may fail to create queues and open, because of waiting for the HW response and timed out.
Sample dmesg:
[ 528.610840] mana 39d4:00:02.0: HWC: Request timed out! [ 528.614452] mana 39d4:00:02.0: Failed to send mana message: -110, 0x0 [ 528.618326] mana 39d4:00:02.0 enP14804s2: Failed to create WQ object: -110
To fix it, move posting of rx wqe before complete(&ctx->comp_event).
--- drivers/net/ethernet/microsoft/mana/hw_channel.c | 62 ++++++++++++----------- 1 file changed, 34 insertions(+), 28 deletions(-)
drivers/net/ethernet/microsoft/mana/hw_channel.c +34 -28
@@ -51,9 +51,33 @@ static int mana_hwc_verify_resp_msg(consreturn 0 ; } +static int mana_hwc_post_rx_wqe (const struct hwc_wq *hwc_rxq, +struct hwc_work_request *req) +{ +struct device *dev = hwc_rxq->hwc->dev; +struct gdma_sge *sge; +int err; + + sge = &req->sge; + sge->address = (u64 )req->buf_sge_addr; + sge->mem_key = hwc_rxq->msg_buf->gpa_mkey; + sge->size = req->buf_len; + +memset (&req->wqe_req,0 ,sizeof (struct gdma_wqe_request )); + req->wqe_req.sgl = sge; + req->wqe_req.num_sge =1 ; + req->wqe_req.client_data_unit =0 ; + + err =mana_gd_post_and_ring (hwc_rxq->gdma_wq, &req->wqe_req,NULL ); +if (err) +dev_err (dev,"Failed to post WQE on HWC RQ: %d\n" , err); +return err; +} +static void mana_hwc_handle_resp (struct hw_channel_context *hwc,u32 resp_len, -const struct gdma_resp_hdr *resp_msg) +struct hwc_work_request *rx_req) { +const struct gdma_resp_hdr *resp_msg = rx_req->buf_va;struct hwc_caller_ctx *ctx;int err;
@@ -61,6 +85,7 @@ static void mana_hwc_handle_resp(struct hwc->inflight_msg_res.map)) {dev_err (hwc->dev,"hwc_rx: invalid msg_id = %u\n" , resp_msg->response.hwc_msg_id); +mana_hwc_post_rx_wqe (hwc->rxq, rx_req);return ; }
@@ -74,30 +99,13 @@ static void mana_hwc_handle_resp(structmemcpy (ctx->output_buf, resp_msg, resp_len); out: ctx->error = err; -complete (&ctx->comp_event); -} - -static int mana_hwc_post_rx_wqe (const struct hwc_wq *hwc_rxq, -struct hwc_work_request *req) -{ -struct device *dev = hwc_rxq->hwc->dev; -struct gdma_sge *sge; -int err; - - sge = &req->sge; - sge->address = (u64 )req->buf_sge_addr; - sge->mem_key = hwc_rxq->msg_buf->gpa_mkey; - sge->size = req->buf_len; -memset (&req->wqe_req,0 ,sizeof (struct gdma_wqe_request )); - req->wqe_req.sgl = sge; - req->wqe_req.num_sge =1 ; - req->wqe_req.client_data_unit =0 ; +/* Must post rx wqe before complete(), otherwise the next rx may +* hit no_wqe error. +*/ +mana_hwc_post_rx_wqe (hwc->rxq, rx_req); - err =mana_gd_post_and_ring (hwc_rxq->gdma_wq, &req->wqe_req,NULL ); -if (err) -dev_err (dev,"Failed to post WQE on HWC RQ: %d\n" , err); -return err; +complete (&ctx->comp_event); } static void mana_hwc_init_event_handler(void *ctx, struct gdma_queue *q_self,
@@ -208,14 +216,12 @@ static void mana_hwc_rx_event_handler(voreturn ; } -mana_hwc_handle_resp (hwc, rx_oob->tx_oob_data_size, resp); +mana_hwc_handle_resp (hwc, rx_oob->tx_oob_data_size, rx_req); -/* Do no longer use 'resp', because the buffer is posted to the HW -* in the below mana_hwc_post_rx_wqe(). +/* Can no longer use 'resp', because the buffer is posted to the HW +* in mana_hwc_handle_resp() above. */ resp =NULL ; - -mana_hwc_post_rx_wqe (hwc_rxq, rx_req); } static void mana_hwc_tx_event_handler(void *ctx, u32 gdma_txq_id,
Greg Kroah-Hartman
maintainerPATCH 181/215 mptcp: sched: check both backup in retrans
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthieu Baerts (NGI0) <[email protected]>
commit 2a1f596ebb23eadc0f9b95a8012e18ef76295fc8 upstream.
The 'mptcp_subflow_context' structure has two items related to the backup flags:
- 'backup': the subflow has been marked as backup by the other peer
- 'request_bkup': the backup flag has been set by the host
Looking only at the 'backup' flag can make sense in some cases, but it is not the behaviour of the default packet scheduler when selecting paths.
As explained in the commit b6a66e521a20 ("mptcp: sched: check both directions for backup"), the packet scheduler should look at both flags, because that was the behaviour from the beginning: the 'backup' flag was set by accident instead of the 'request_bkup' one. Now that the latter has been fixed, get_retrans() needs to be adapted as well.
--- net/mptcp/protocol.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/mptcp/protocol.c +1 -1
@@ -2213,7 +2213,7 @@ static struct sock *mptcp_subflow_get_recontinue ; } -if (subflow->backup) { +if (subflow->backup || subflow->request_bkup) {if (!backup) backup = ssk;continue ;
Greg Kroah-Hartman
maintainerPATCH 182/215 Revert "MIPS: Loongson64: reset: Prioritise firmware service"
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <[email protected]>
This reverts commit 77011a1d7a1a973d1657d06b658ce20f94172827 which is commit 4e7ca0b57f3bc09ba3e4ab86bf6b7c35134bfd04 upstream.
Turns out to break the 5.15.y build, it should not have been backported that far.
--- arch/mips/loongson64/reset.c | 38 ++++++++++++++++++++++---------------- 1 file changed, 22 insertions(+), 16 deletions(-)
arch/mips/loongson64/reset.c +22 -16
@@ -11,7 +11,6 @@#include <linux/init.h> #include <linux/kexec.h> #include <linux/pm.h> -#include <linux/reboot.h> #include <linux/slab.h> #include <asm/bootinfo.h>
@@ -22,21 +21,36 @@#include <loongson.h> #include <boot_param.h> -static int firmware_restart (struct sys_off_data *unusedd) +static void loongson_restart (char *command) {void (*fw_restart)(void ) = (void *)loongson_sysconf.restart_addr;fw_restart (); -return NOTIFY_DONE ; +while (1 ) { +if (cpu_wait) +cpu_wait (); + } } -static int firmware_poweroff (struct sys_off_data *unused) +static void loongson_poweroff (void ) {void (*fw_poweroff)(void ) = (void *)loongson_sysconf.poweroff_addr;fw_poweroff (); -return NOTIFY_DONE ; +while (1 ) { +if (cpu_wait) +cpu_wait (); + } +} + +static void loongson_halt (void ) +{ +pr_notice ("\n\n** You can safely turn off the power now **\n\n" ); +while (1 ) { +if (cpu_wait) +cpu_wait (); + } }#ifdef CONFIG_KEXEC
@@ -140,17 +154,9 @@ static void loongson_crash_shutdown(strustatic int __init mips_reboot_setup (void ) { -if (loongson_sysconf.restart_addr) { -register_sys_off_handler (SYS_OFF_MODE_RESTART , -SYS_OFF_PRIO_FIRMWARE , - firmware_restart,NULL ); - } - -if (loongson_sysconf.poweroff_addr) { -register_sys_off_handler (SYS_OFF_MODE_POWER_OFF , -SYS_OFF_PRIO_FIRMWARE , - firmware_poweroff,NULL ); - } + _machine_restart = loongson_restart; + _machine_halt = loongson_halt; + pm_power_off = loongson_poweroff;#ifdef CONFIG_KEXEC kexec_argv =kmalloc (KEXEC_ARGV_SIZE ,GFP_KERNEL );
Greg Kroah-Hartman
maintainerPATCH 183/215 drm/amdkfd: dont allow mapping the MMIO HDP page with large pages
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit be4a2a81b6b90d1a47eaeaace4cc8e2cb57b96c7 upstream.
We don't get the right offset in that case. The GPU has an unused 4K area of the register BAR space into which you can remap registers. We remap the HDP flush registers into this space to allow userspace (CPU or GPU) to flush the HDP when it updates VRAM. However, on systems with >4K pages, we end up exposing PAGE_SIZE of MMIO space.
--- drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c +4 -1
@@ -1290,7 +1290,7 @@ static int kfd_ioctl_alloc_memory_of_gpu goto err_unlock; } offset =amdgpu_amdkfd_get_mmio_remap_phys_addr (dev->kgd); -if (!offset) { +if (!offset || (PAGE_SIZE >4096 )) { err = -ENOMEM ; goto err_unlock; }
@@ -2029,6 +2029,9 @@ static int kfd_mmio_mmap(struct kfd_devif (vma->vm_end - vma->vm_start !=PAGE_SIZE )return -EINVAL ; +if (PAGE_SIZE >4096 ) +return -EINVAL ; + address =amdgpu_amdkfd_get_mmio_remap_phys_addr (dev->kgd); vma->vm_flags |= VM_IO | VM_DONTCOPY | VM_DONTEXPAND | VM_NORESERVE |
Greg Kroah-Hartman
maintainerPATCH 184/215 ata: libata-core: Fix null pointer dereference on error
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Niklas Cassel <[email protected]>
commit 5d92c7c566dc76d96e0e19e481d926bbe6631c1e upstream.
If the ata_port_alloc() call in ata_host_alloc() fails, ata_host_release() will get called.
However, the code in ata_host_release() tries to free ata_port struct members unconditionally, which can lead to the following:
BUG: unable to handle page fault for address: 0000000000003990 PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 10 PID: 594 Comm: (udev-worker) Not tainted 6.10.0-rc5 #44 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:ata_host_release.cold+0x2f/0x6e [libata] Code: e4 4d 63 f4 44 89 e2 48 c7 c6 90 ad 32 c0 48 c7 c7 d0 70 33 c0 49 83 c6 0e 41 RSP: 0018:ffffc90000ebb968 EFLAGS: 00010246 RAX: 0000000000000041 RBX: ffff88810fb52e78 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88813b3218c0 RDI: ffff88813b3218c0 RBP: ffff88810fb52e40 R08: 0000000000000000 R09: 6c65725f74736f68 R10: ffffc90000ebb738 R11: 73692033203a746e R12: 0000000000000004 R13: 0000000000000000 R14: 0000000000000011 R15: 0000000000000006 FS: 00007f6cc55b9980(0000) GS:ffff88813b300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000003990 CR3: 00000001122a2000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15a/0x2f0 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? ata_host_release.cold+0x2f/0x6e [libata] ? ata_host_release.cold+0x2f/0x6e [libata] release_nodes+0x35/0xb0 devres_release_group+0x113/0x140 ata_host_alloc+0xed/0x120 [libata] ata_host_alloc_pinfo+0x14/0xa0 [libata] ahci_init_one+0x6c9/0xd20 [ahci]
Do not access ata_port struct members unconditionally.
--- drivers/ata/libata-core.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/ata/libata-core.c +3 -0
@@ -5391,6 +5391,9 @@ static void ata_host_release(struct kreffor (i =0 ; i < host->n_ports; i++) {struct ata_port *ap = host->ports[i]; +if (!ap) +continue ; +kfree (ap->pmp_link);kfree (ap->slave_link);kfree (ap);
Greg Kroah-Hartman
maintainerPATCH 185/215 cgroup/cpuset: Prevent UAF in proc_cpuset_show()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chen Ridong <[email protected]>
commit 1be59c97c83ccd67a519d8a49486b3a8a73ca28a upstream.
An UAF can happen when /proc/cpuset is read as reported in [1].
This can be reproduced by the following methods:
1.add an mdelay(1000) before acquiring the cgroup_lock In the
cgroup_path_ns function.
2.$cat /proc/<pid>/cpuset repeatly.
3.$mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset/
$umount /sys/fs/cgroup/cpuset/ repeatly.
The race that cause this bug can be shown as below:
(umount) | (cat /proc/<pid>/cpuset)css_release | proc_cpuset_showcss_release_work_fn | css = task_get_css(tsk, cpuset_cgrp_id);css_free_rwork_fn | cgroup_path_ns(css->cgroup, ...);cgroup_destroy_root | mutex_lock(&cgroup_mutex);rebind_subsystems |cgroup_free_root |
| // cgrp was freed, UAF | cgroup_path_ns_locked(cgrp,..);
When the cpuset is initialized, the root node top_cpuset.css.cgrp will point to &cgrp_dfl_root.cgrp. In cgroup v1, the mount operation will allocate cgroup_root, and top_cpuset.css.cgrp will point to the allocated &cgroup_root.cgrp. When the umount operation is executed, top_cpuset.css.cgrp will be rebound to &cgrp_dfl_root.cgrp.
The problem is that when rebinding to cgrp_dfl_root, there are cases where the cgroup_root allocated by setting up the root for cgroup v1 is cached. This could lead to a Use-After-Free (UAF) if it is subsequently freed. The descendant cgroups of cgroup v1 can only be freed after the css is released. However, the css of the root will never be released, yet the cgroup_root should be freed when it is unmounted. This means that obtaining a reference to the css of the root does not guarantee that css.cgrp->root will not be freed.
Fix this problem by using rcu_read_lock in proc_cpuset_show(). As cgroup_root is kfree_rcu after commit d23b5c577715 ("cgroup: Make operations on the cgroup root_list RCU safe"), css->cgroup won't be freed during the critical section.
To call cgroup_path_ns_locked, css_set_lock is needed, so it is safe to replace task_get_css with task_css.
[1] https://syzkaller.appspot.com/bug?extid=9b1ff7be974a403aa4cd
--- kernel/cgroup/cpuset.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-)
kernel/cgroup/cpuset.c +9 -4
@@ -22,6 +22,7 @@* distribution for more details. */ +#include "cgroup-internal.h" #include <linux/cpu.h> #include <linux/cpumask.h> #include <linux/cpuset.h>
@@ -3780,10 +3781,14 @@ int proc_cpuset_show(struct seq_file *m,if (!buf) goto out; - css =task_get_css (tsk, cpuset_cgrp_id); - retval =cgroup_path_ns (css->cgroup, buf,PATH_MAX , - current->nsproxy->cgroup_ns); -css_put (css); +rcu_read_lock (); +spin_lock_irq (&css_set_lock); + css =task_css (tsk, cpuset_cgrp_id); + retval =cgroup_path_ns_locked (css->cgroup, buf,PATH_MAX , + current->nsproxy->cgroup_ns); +spin_unlock_irq (&css_set_lock); +rcu_read_unlock (); +if (retval >=PATH_MAX ) retval = -ENAMETOOLONG ;if (retval <0 )
Greg Kroah-Hartman
maintainerPATCH 186/215 net:rds: Fix possible deadlock in rds_message_put
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Allison Henderson <[email protected]>
commit f1acf1ac84d2ae97b7889b87223c1064df850069 upstream.
Functions rds_still_queued and rds_clear_recv_queue lock a given socket in order to safely iterate over the incoming rds messages. However calling rds_inc_put while under this lock creates a potential deadlock. rds_inc_put may eventually call rds_message_purge, which will lock m_rs_lock. This is the incorrect locking order since m_rs_lock is meant to be locked before the socket. To fix this, we move the message item to a local list or variable that wont need rs_recv_lock protection. Then we can safely call rds_inc_put on any item stored locally after rs_recv_lock is released.
--- net/rds/recv.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-)
net/rds/recv.c +11 -2
@@ -424,6 +424,7 @@ static int rds_still_queued(struct rds_sstruct sock *sk =rds_rs_to_sk (rs);int ret =0 ;unsigned long flags; +struct rds_incoming *to_drop =NULL ;write_lock_irqsave (&rs->rs_recv_lock, flags);if (!list_empty (&inc->i_item)) {
@@ -434,11 +435,14 @@ static int rds_still_queued(struct rds_s -be32_to_cpu (inc->i_hdr.h_len), inc->i_hdr.h_dport);list_del_init (&inc->i_item); -rds_inc_put (inc); + to_drop = inc; } }write_unlock_irqrestore (&rs->rs_recv_lock, flags); +if (to_drop) +rds_inc_put (to_drop); +rdsdebug ("inc %p rs %p still %d dropped %d\n" , inc, rs, ret, drop);return ret; }
@@ -757,16 +761,21 @@ void rds_clear_recv_queue(struct rds_socstruct sock *sk =rds_rs_to_sk (rs);struct rds_incoming *inc, *tmp;unsigned long flags; +LIST_HEAD (to_drop);write_lock_irqsave (&rs->rs_recv_lock, flags);list_for_each_entry_safe (inc, tmp, &rs->rs_recv_queue, i_item) {rds_recv_rcvbuf_delta (rs, sk, inc->i_conn->c_lcong, -be32_to_cpu (inc->i_hdr.h_len), inc->i_hdr.h_dport); +list_move (&inc->i_item, &to_drop); + } +write_unlock_irqrestore (&rs->rs_recv_lock, flags); + +list_for_each_entry_safe (inc, tmp, &to_drop, i_item) {list_del_init (&inc->i_item);rds_inc_put (inc); } -write_unlock_irqrestore (&rs->rs_recv_lock, flags); }/*
Greg Kroah-Hartman
maintainerPATCH 187/215 ksmbd: the buffer of smb2 query dir response has at least 1 byte
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Namjae Jeon <[email protected]>
[ Upstream commit ce61b605a00502c59311d0a4b1f58d62b48272d0 ]
When STATUS_NO_MORE_FILES status is set to smb2 query dir response, ->StructureSize is set to 9, which mean buffer has 1 byte. This issue occurs because ->Buffer[1] in smb2_query_directory_rsp to flex-array.
--- fs/ksmbd/smb2pdu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
fs/ksmbd/smb2pdu.c +2 -1
@@ -4160,7 +4160,8 @@ int smb2_query_dir(struct ksmbd_work *work) rsp->OutputBufferLength =cpu_to_le32 (0 ); rsp->Buffer[0 ] =0 ; rc =ksmbd_iov_pin_rsp (work, (void *)rsp, -sizeof (struct smb2_query_directory_rsp )); + offsetof(struct smb2_query_directory_rsp , Buffer) + +1 );if (rc) goto err_out; }else {
Signature · 1 line
2.43.0
Re: [PATCH 5.15 187/215] ksmbd: the buffer of smb2 query dir response has at least 1 byte
Quoted 1 line · Greg Kroah-Hartman
Hi Greg,
Quoted 1 line
5.15-stable review patch. If anyone has any objections, please let me know.
Please drop this patch.
I told you this patch was required for 6.1 kernel versions or later in previous mail.
Thanks!
Quoted 40 lines
------------------
From: Namjae Jeon <[email protected]>
[ Upstream commit
ce61b605a00502c59311d0a4b1f58d62b48272d0]When
STATUS_NO_MORE_FILESstatus is set to smb2 query dir response, ->StructureSize is set to 9, which mean buffer has 1 byte. This issue occurs because ->Buffer[1] insmb2_query_directory_rspto flex-array.Fixes eb3e28c1e89b ("smb3: Replace smb2pdu 1-element arrays with flex-arrays")Cc [email protected] # v6.1+Signed-off-by Namjae Jeon <[email protected]>Signed-off-by Steve French <[email protected]>Signed-off-by Sasha Levin <[email protected]>--- fs/ksmbd/smb2pdu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)fs/ksmbd/smb2pdu.c +2
-2@@ -4160,7 +4160,8 @@ int smb2_query_dir(struct ksmbd_work *work) rsp->OutputBufferLength =cpu_to_le32 (0 ); rsp->Buffer[0 ] =0 ; rc =ksmbd_iov_pin_rsp (work, (void *)rsp, -sizeof (struct smb2_query_directory_rsp )); + offsetof(struct smb2_query_directory_rsp , Buffer) + +1 );if (rc) goto err_out; }else { --2.43.0
Greg Kroah-Hartman
maintainerRe: [PATCH 5.15 187/215] ksmbd: the buffer of smb2 query dir response has at least 1 byte
Quoted 8 lines · Namjae Jeon
Quoted 1 line · Greg Kroah-Hartman
Hi Greg,
Quoted 1 line
5.15-stable review patch. If anyone has any objections, please let me know.
Please drop this patch.
I told you this patch was required for 6.1 kernel versions or later in previous mail.
This was added because commit eb3e28c1e89b ("smb3: Replace smb2pdu 1-element arrays with flex-arrays") has been backported to 5.15 and 5.10 stable kernels.
But hey, I'll go drop it now, and will be glad to add it back later if needed.
thanks,
greg k-h
Greg Kroah-Hartman
maintainerPATCH 188/215 soundwire: stream: fix programming slave ports for non-continous port maps
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Krzysztof Kozlowski <[email protected]>
commit ab8d66d132bc8f1992d3eb6cab8d32dda6733c84 upstream.
Two bitmasks in 'struct sdw_slave_prop' - 'source_ports' and 'sink_ports' - define which ports to program in sdw_program_slave_port_params(). The masks are used to get the appropriate data port properties ('struct sdw_get_slave_dpn_prop') from an array.
Bitmasks can be non-continuous or can start from index different than 0, thus when looking for matching port property for given port, we must iterate over mask bits, not from 0 up to number of ports.
This fixes allocation and programming slave ports, when a source or sink masks start from further index.
--- drivers/soundwire/stream.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/soundwire/stream.c +4 -4
@@ -1445,18 +1445,18 @@ struct sdw_dpn_prop *sdw_get_slave_dpn_p unsigned int port_num) {struct sdw_dpn_prop *dpn_prop; -u8 num_ports; +unsigned long mask;int i;if (direction ==SDW_DATA_DIR_TX ) { - num_ports =hweight32 (slave->prop.source_ports); + mask = slave->prop.source_ports; dpn_prop = slave->prop.src_dpn_prop; }else { - num_ports =hweight32 (slave->prop.sink_ports); + mask = slave->prop.sink_ports; dpn_prop = slave->prop.sink_dpn_prop; } -for (i =0 ; i < num_ports; i++) { +for_each_set_bit (i, &mask,32 ) {if (dpn_prop[i].num == port_num)return &dpn_prop[i]; }
Greg Kroah-Hartman
maintainerPATCH 189/215 PM: core: Remove DEFINE_UNIVERSAL_DEV_PM_OPS() macro
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Cercueil <[email protected]>
[ Upstream commit 3f4b32511a77bc5a05cfbf26fec94c4e1b1cf46a ]
The deprecated UNIVERSAL_DEV_PM_OPS() macro uses the provided callbacks for both runtime PM and system sleep, which is very likely to be a mistake, as a system sleep can be triggered while a given device is already PM-suspended, which would cause the suspend callback to be called twice.
The amount of users of UNIVERSAL_DEV_PM_OPS() is also tiny (16 occurences) compared to the number of places where SET_SYSTEM_SLEEP_PM_OPS() is used with pm_runtime_force_suspend() and pm_runtime_force_resume(), which makes me think that none of these cases are actually valid.
As the new macro DEFINE_UNIVERSAL_DEV_PM_OPS() which was introduced to replace UNIVERSAL_DEV_PM_OPS() is currently unused, remove it before someone starts to use it in yet another invalid case.
Stable-dep-of: 5af9b304bc60 ("phy: xilinx: phy-zynqmp: Fix SGMII linkup failure on resume")
--- include/linux/pm.h | 21 ++++++++------------- 1 file changed, 8 insertions(+), 13 deletions(-)
include/linux/pm.h +8 -13
@@ -366,6 +366,12 @@ const struct dev_pm_ops name = { \ SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \ } +/* Deprecated. Use DEFINE_SIMPLE_DEV_PM_OPS() instead. */ +#define SIMPLE_DEV_PM_OPS (name, suspend_fn, resume_fn) \ +const struct dev_pm_ops __maybe_unused name = { \ + SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \ +} +/* * Use this for defining a set of PM operations to be used in all situations * (system suspend, hibernation or runtime PM).
@@ -378,20 +384,9 @@ const struct dev_pm_ops name = { \* suspend and "early" resume callback pointers, .suspend_late() and * .resume_early(), to the same routines as .runtime_suspend() and * .runtime_resume(), respectively (and analogously for hibernation). +* +* Deprecated. You most likely don't want this macro. */ -#define DEFINE_UNIVERSAL_DEV_PM_OPS (name, suspend_fn, resume_fn, idle_fn) \ -static const struct dev_pm_ops name = { \ - SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \ - RUNTIME_PM_OPS(suspend_fn, resume_fn, idle_fn) \ -} - -/* Deprecated. Use DEFINE_SIMPLE_DEV_PM_OPS() instead. */ -#define SIMPLE_DEV_PM_OPS (name, suspend_fn, resume_fn) \ -const struct dev_pm_ops __maybe_unused name = { \ - SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \ -} - -/* Deprecated. Use DEFINE_UNIVERSAL_DEV_PM_OPS() instead. */ #define UNIVERSAL_DEV_PM_OPS (name, suspend_fn, resume_fn, idle_fn) \ const struct dev_pm_ops __maybe_unused name = { \ SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 190/215 PM: core: Add EXPORT[_GPL]_SIMPLE_DEV_PM_OPS macros
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Cercueil <[email protected]>
[ Upstream commit 0ae101fdd3297b7165755340e05386f1e1379709 ]
These macros are defined conditionally, according to CONFIG_PM:
- if CONFIG_PM is enabled, these macros resolve to DEFINE_SIMPLE_DEV_PM_OPS(), and the dev_pm_ops symbol will be exported.
- if CONFIG_PM is disabled, these macros will result in a dummy static dev_pm_ops to be created with the __maybe_unused flag. The dev_pm_ops will then be discarded by the compiler, along with the provided callback functions if they are not used anywhere else.
In the second case, the symbol is not exported, which should be perfectly fine - users of the symbol should all use the pm_ptr() or pm_sleep_ptr() macro, so the dev_pm_ops marked as "extern" in the client's code will never be accessed.
Stable-dep-of: 5af9b304bc60 ("phy: xilinx: phy-zynqmp: Fix SGMII linkup failure on resume")
--- include/linux/pm.h | 35 ++++++++++++++++++++++++++++++++--- 1 file changed, 32 insertions(+), 3 deletions(-)
include/linux/pm.h +32 -3
@@ -8,6 +8,7 @@#ifndef _LINUX_PM_H#define _LINUX_PM_H +#include <linux/export.h> #include <linux/list.h> #include <linux/workqueue.h> #include <linux/spinlock.h>
@@ -357,14 +358,42 @@ struct dev_pm_ops {#define SET_RUNTIME_PM_OPS (suspend_fn, resume_fn, idle_fn)#endif +#define _DEFINE_DEV_PM_OPS (name, \ + suspend_fn, resume_fn, \ + runtime_suspend_fn, runtime_resume_fn, idle_fn) \ +const struct dev_pm_ops name = { \ + SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \ + RUNTIME_PM_OPS(runtime_suspend_fn, runtime_resume_fn, idle_fn) \ +} + +#ifdef CONFIG_PM +#define _EXPORT_DEV_PM_OPS (name, suspend_fn, resume_fn, runtime_suspend_fn, \ + runtime_resume_fn, idle_fn, sec) \ + _DEFINE_DEV_PM_OPS(name, suspend_fn, resume_fn, runtime_suspend_fn, \ + runtime_resume_fn, idle_fn); \ + _EXPORT_SYMBOL(name, sec) +#else +#define _EXPORT_DEV_PM_OPS (name, suspend_fn, resume_fn, runtime_suspend_fn, \ + runtime_resume_fn, idle_fn, sec) \ +static __maybe_unused _DEFINE_DEV_PM_OPS(__static_##name, suspend_fn, \ + resume_fn, runtime_suspend_fn, \ + runtime_resume_fn, idle_fn) +#endif +/* * Use this if you want to use the same suspend and resume callbacks for suspend * to RAM and hibernation. +* +* If the underlying dev_pm_ops struct symbol has to be exported, use +* EXPORT_SIMPLE_DEV_PM_OPS() or EXPORT_GPL_SIMPLE_DEV_PM_OPS() instead. */ #define DEFINE_SIMPLE_DEV_PM_OPS (name, suspend_fn, resume_fn) \ -const struct dev_pm_ops name = { \ - SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \ -} + _DEFINE_DEV_PM_OPS(name, suspend_fn, resume_fn, NULL, NULL, NULL) + +#define EXPORT_SIMPLE_DEV_PM_OPS (name, suspend_fn, resume_fn) \ + _EXPORT_DEV_PM_OPS(name, suspend_fn, resume_fn, NULL, NULL, NULL, "") +#define EXPORT_GPL_SIMPLE_DEV_PM_OPS (name, suspend_fn, resume_fn) \ + _EXPORT_DEV_PM_OPS(name, suspend_fn, resume_fn, NULL, NULL, NULL, "_gpl")/* Deprecated. Use DEFINE_SIMPLE_DEV_PM_OPS() instead. */ #define SIMPLE_DEV_PM_OPS (name, suspend_fn, resume_fn) \
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 191/215 PM: runtime: Add DEFINE_RUNTIME_DEV_PM_OPS() macro
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Cercueil <[email protected]>
[ Upstream commit 9d8619190031af0a314bee865262d8975473e4dd ]
A lot of drivers create a dev_pm_ops struct with the system sleep suspend/resume callbacks set to pm_runtime_force_suspend() and pm_runtime_force_resume().
These drivers can now use the DEFINE_RUNTIME_DEV_PM_OPS() macro, which will use pm_runtime_force_{suspend,resume}() as the system sleep callbacks, while having the same dead code removal characteristic that is already provided by DEFINE_SIMPLE_DEV_PM_OPS().
Stable-dep-of: 5af9b304bc60 ("phy: xilinx: phy-zynqmp: Fix SGMII linkup failure on resume")
--- include/linux/pm.h | 3 ++- include/linux/pm_runtime.h | 14 ++++++++++++++ 2 files changed, 16 insertions(+), 1 deletion(-)
include/linux/pm.h +2 -1
@@ -414,7 +414,8 @@ const struct dev_pm_ops __maybe_unused name = { \* .resume_early(), to the same routines as .runtime_suspend() and * .runtime_resume(), respectively (and analogously for hibernation). * -* Deprecated. You most likely don't want this macro. +* Deprecated. You most likely don't want this macro. Use +* DEFINE_RUNTIME_DEV_PM_OPS() instead. */ #define UNIVERSAL_DEV_PM_OPS (name, suspend_fn, resume_fn, idle_fn) \ const struct dev_pm_ops __maybe_unused name = { \
include/linux/pm_runtime.h +14 -0
@@ -22,6 +22,20 @@usage_count */ #define RPM_AUTO 0x08/* Use autosuspend_delay */ +/* +* Use this for defining a set of PM operations to be used in all situations +* (system suspend, hibernation or runtime PM). +* +* Note that the behaviour differs from the deprecated UNIVERSAL_DEV_PM_OPS() +* macro, which uses the provided callbacks for both runtime PM and system +* sleep, while DEFINE_RUNTIME_DEV_PM_OPS() uses pm_runtime_force_suspend() +* and pm_runtime_force_resume() for its system sleep callbacks. +*/ +#define DEFINE_RUNTIME_DEV_PM_OPS (name, suspend_fn, resume_fn, idle_fn) \ + _DEFINE_DEV_PM_OPS(name, pm_runtime_force_suspend, \ + pm_runtime_force_resume, suspend_fn, \ + resume_fn, idle_fn) +#ifdef CONFIG_PM extern struct workqueue_struct *pm_wq;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 192/215 phy: xilinx: add runtime PM support
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Piyush Mehta <[email protected]>
[ Upstream commit b3db66f624468ab4a0385586bc7f4221e477d6b2 ]
Added Runtime power management support to the xilinx phy driver and using DEFINE_RUNTIME_DEV_PM_OPS new macros allows the compiler to remove the unused dev_pm_ops structure and related functions if !CONFIG_PM without the need to mark the functions __maybe_unused.
Stable-dep-of: 5af9b304bc60 ("phy: xilinx: phy-zynqmp: Fix SGMII linkup failure on resume")
--- drivers/phy/xilinx/phy-zynqmp.c | 35 ++++++++++++++++++++++++++------- 1 file changed, 28 insertions(+), 7 deletions(-)
drivers/phy/xilinx/phy-zynqmp.c +28 -7
@@ -21,6 +21,7 @@#include <linux/of.h> #include <linux/phy/phy.h> #include <linux/platform_device.h> +#include <linux/pm_runtime.h> #include <linux/slab.h> #include <dt-bindings/phy/phy.h>
@@ -821,7 +822,7 @@ static struct phy *xpsgtr_xlate(struct device *dev,* Power Management */ -static int __maybe_unused xpsgtr_suspend (struct device *dev) +static int xpsgtr_runtime_suspend (struct device *dev) {struct xpsgtr_dev *gtr_dev =dev_get_drvdata (dev);unsigned int i;
@@ -836,7 +837,7 @@ static int __maybe_unused xpsgtr_suspend(struct device *dev)return 0 ; } -static int __maybe_unused xpsgtr_resume (struct device *dev) +static int xpsgtr_runtime_resume (struct device *dev) {struct xpsgtr_dev *gtr_dev =dev_get_drvdata (dev);unsigned int icm_cfg0, icm_cfg1;
@@ -877,10 +878,8 @@ static int __maybe_unused xpsgtr_resume(struct device *dev)return err; } -static const struct dev_pm_ops xpsgtr_pm_ops = { -SET_SYSTEM_SLEEP_PM_OPS (xpsgtr_suspend, xpsgtr_resume) -}; - +static DEFINE_RUNTIME_DEV_PM_OPS(xpsgtr_pm_ops, xpsgtr_runtime_suspend, + xpsgtr_runtime_resume, NULL);/* * Probe & Platform Driver */
@@ -1006,6 +1005,16 @@ static int xpsgtr_probe(struct platform_device *pdev) ret =PTR_ERR (provider); goto err_clk_put; } + +pm_runtime_set_active (gtr_dev->dev); +pm_runtime_enable (gtr_dev->dev); + + ret =pm_runtime_resume_and_get (gtr_dev->dev); +if (ret <0 ) { +pm_runtime_disable (gtr_dev->dev); + goto err_clk_put; + } +return 0 ; err_clk_put:
@@ -1015,6 +1024,17 @@ static int xpsgtr_probe(struct platform_device *pdev)return ret; } +static int xpsgtr_remove (struct platform_device *pdev) +{ +struct xpsgtr_dev *gtr_dev =platform_get_drvdata (pdev); + +pm_runtime_disable (gtr_dev->dev); +pm_runtime_put_noidle (gtr_dev->dev); +pm_runtime_set_suspended (gtr_dev->dev); + +return 0 ; +} +static const struct of_device_id xpsgtr_of_match[] = { { .compatible ="xlnx,zynqmp-psgtr" , }, { .compatible ="xlnx,zynqmp-psgtr-v1.1" , },
@@ -1024,10 +1044,11 @@ MODULE_DEVICE_TABLE(of, xpsgtr_of_match);static struct platform_driver xpsgtr_driver = { .probe = xpsgtr_probe, + .remove = xpsgtr_remove, .driver = { .name ="xilinx-psgtr" , .of_match_table = xpsgtr_of_match, - .pm = &xpsgtr_pm_ops, + .pm =pm_ptr (&xpsgtr_pm_ops), }, };
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 193/215 phy: xilinx: phy-zynqmp: dynamic clock support for power-save
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Piyush Mehta <[email protected]>
[ Upstream commit 25d70083351318b44ae699d92c042dcb18a738ea ]
Enabling clock for all the lanes consumes power even PHY is active or inactive. To resolve this, enable/disable clocks in phy_init/phy_exit.
By default clock is disabled for all the lanes. Whenever phy_init called from USB, SATA, or display driver, etc. It enabled the required clock for requested lane. On phy_exit cycle, it disabled clock for the active PHYs.
During the suspend/resume cycle, each USB/ SATA/ display driver called phy_exit/phy_init individually. It disabled clock on exit, and enabled on initialization for the active PHYs.
Stable-dep-of: 5af9b304bc60 ("phy: xilinx: phy-zynqmp: Fix SGMII linkup failure on resume")
--- drivers/phy/xilinx/phy-zynqmp.c | 61 ++++++++------------------------- 1 file changed, 15 insertions(+), 46 deletions(-)
drivers/phy/xilinx/phy-zynqmp.c +15 -46
@@ -573,6 +573,10 @@ static int xpsgtr_phy_init(struct phy *phy)mutex_lock (>r_dev->gtr_mutex); +/* Configure and enable the clock when peripheral phy_init call */ +if (clk_prepare_enable (gtr_dev->clk[gtr_phy->lane])) + goto out; +/* Skip initialization if not required. */ if (!xpsgtr_phy_init_required (gtr_phy)) goto out;
@@ -617,9 +621,13 @@ static int xpsgtr_phy_init(struct phy *phy)static int xpsgtr_phy_exit (struct phy *phy) {struct xpsgtr_phy *gtr_phy =phy_get_drvdata (phy); +struct xpsgtr_dev *gtr_dev = gtr_phy->dev; gtr_phy->skip_phy_init = false; +/* Ensure that disable clock only, which configure for lane */ +clk_disable_unprepare (gtr_dev->clk[gtr_phy->lane]); +return 0 ; }
@@ -825,15 +833,11 @@ static struct phy *xpsgtr_xlate(struct device *dev,static int xpsgtr_runtime_suspend (struct device *dev) {struct xpsgtr_dev *gtr_dev =dev_get_drvdata (dev); -unsigned int i;/* Save the snapshot ICM_CFG registers. */ gtr_dev->saved_icm_cfg0 =xpsgtr_read (gtr_dev,ICM_CFG0 ); gtr_dev->saved_icm_cfg1 =xpsgtr_read (gtr_dev,ICM_CFG1 ); -for (i =0 ; i <ARRAY_SIZE (gtr_dev->clk); i++) -clk_disable_unprepare (gtr_dev->clk[i]); -return 0 ; }
@@ -843,13 +847,6 @@ static int xpsgtr_runtime_resume(struct device *dev)unsigned int icm_cfg0, icm_cfg1;unsigned int i;bool skip_phy_init; -int err; - -for (i =0 ; i <ARRAY_SIZE (gtr_dev->clk); i++) { - err =clk_prepare_enable (gtr_dev->clk[i]); -if (err) - goto err_clk_put; - } icm_cfg0 =xpsgtr_read (gtr_dev,ICM_CFG0 ); icm_cfg1 =xpsgtr_read (gtr_dev,ICM_CFG1 );
@@ -870,12 +867,6 @@ static int xpsgtr_runtime_resume(struct device *dev) gtr_dev->phys[i].skip_phy_init = skip_phy_init;return 0 ; - -err_clk_put: -while (i--) -clk_disable_unprepare (gtr_dev->clk[i]); - -return err; } static DEFINE_RUNTIME_DEV_PM_OPS(xpsgtr_pm_ops, xpsgtr_runtime_suspend,
@@ -887,7 +878,6 @@ static DEFINE_RUNTIME_DEV_PM_OPS(xpsgtr_pm_ops, xpsgtr_runtime_suspend,static int xpsgtr_get_ref_clocks (struct xpsgtr_dev *gtr_dev) {unsigned int refclk; -int ret;for (refclk =0 ; refclk <ARRAY_SIZE (gtr_dev->refclk_sscs); ++refclk) {unsigned long rate;
@@ -898,19 +888,14 @@ static int xpsgtr_get_ref_clocks(struct xpsgtr_dev *gtr_dev)snprintf (name,sizeof (name),"ref%u" , refclk); clk =devm_clk_get_optional (gtr_dev->dev, name);if (IS_ERR (clk)) { - ret =dev_err_probe (gtr_dev->dev,PTR_ERR (clk), -"Failed to get reference clock %u\n" , - refclk); - goto err_clk_put; +return dev_err_probe (gtr_dev->dev,PTR_ERR (clk), +"Failed to get ref clock %u\n" , + refclk); }if (!clk)continue ; - ret =clk_prepare_enable (clk); -if (ret) - goto err_clk_put; - gtr_dev->clk[refclk] = clk;/*
@@ -930,18 +915,11 @@ static int xpsgtr_get_ref_clocks(struct xpsgtr_dev *gtr_dev)dev_err (gtr_dev->dev,"Invalid rate %lu for reference clock %u\n" , rate, refclk); - ret = -EINVAL ; - goto err_clk_put; +return -EINVAL ; } }return 0 ; - -err_clk_put: -while (refclk--) -clk_disable_unprepare (gtr_dev->clk[refclk]); - -return ret; }static int xpsgtr_probe (struct platform_device *pdev)
@@ -950,7 +928,6 @@ static int xpsgtr_probe(struct platform_device *pdev)struct xpsgtr_dev *gtr_dev;struct phy_provider *provider;unsigned int port; -unsigned int i;int ret; gtr_dev =devm_kzalloc (&pdev->dev,sizeof (*gtr_dev),GFP_KERNEL );
@@ -990,8 +967,7 @@ static int xpsgtr_probe(struct platform_device *pdev) phy =devm_phy_create (&pdev->dev, np, &xpsgtr_phyops);if (IS_ERR (phy)) {dev_err (&pdev->dev,"failed to create PHY\n" ); - ret =PTR_ERR (phy); - goto err_clk_put; +return PTR_ERR (phy); } gtr_phy->phy = phy;
@@ -1002,8 +978,7 @@ static int xpsgtr_probe(struct platform_device *pdev) provider =devm_of_phy_provider_register (&pdev->dev, xpsgtr_xlate);if (IS_ERR (provider)) {dev_err (&pdev->dev,"registering provider failed\n" ); - ret =PTR_ERR (provider); - goto err_clk_put; +return PTR_ERR (provider); }pm_runtime_set_active (gtr_dev->dev);
@@ -1012,16 +987,10 @@ static int xpsgtr_probe(struct platform_device *pdev) ret =pm_runtime_resume_and_get (gtr_dev->dev);if (ret <0 ) {pm_runtime_disable (gtr_dev->dev); - goto err_clk_put; +return ret; }return 0 ; - -err_clk_put: -for (i =0 ; i <ARRAY_SIZE (gtr_dev->clk); i++) -clk_disable_unprepare (gtr_dev->clk[i]); - -return ret; }static int xpsgtr_remove (struct platform_device *pdev)
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 194/215 phy: xilinx: phy-zynqmp: Fix SGMII linkup failure on resume
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Piyush Mehta <[email protected]>
[ Upstream commit 5af9b304bc6010723c02f74de0bfd24ff19b1a10 ]
On a few Kria KR260 Robotics Starter Kit the PS-GEM SGMII linkup is not happening after the resume. This is because serdes registers are reset when FPD is off (in suspend state) and needs to be reprogrammed in the resume path with the same default initialization as done in the first stage bootloader psu_init routine.
To address the failure introduce a set of serdes registers to be saved in the suspend path and then restore it on resume.
--- drivers/phy/xilinx/phy-zynqmp.c | 56 +++++++++++++++++++++++++++++++++ 1 file changed, 56 insertions(+)
drivers/phy/xilinx/phy-zynqmp.c +56 -0
@@ -166,6 +166,24 @@/* Timeout values */ #define TIMEOUT_US 1000 +/* Lane 0/1/2/3 offset */ +#define DIG_8 (n) ((0x4000 * (n)) + 0x1074) +#define ILL13 (n) ((0x4000 * (n)) + 0x1994) +#define DIG_10 (n) ((0x4000 * (n)) + 0x107c) +#define RST_DLY (n) ((0x4000 * (n)) + 0x19a4) +#define BYP_15 (n) ((0x4000 * (n)) + 0x1038) +#define BYP_12 (n) ((0x4000 * (n)) + 0x102c) +#define MISC3 (n) ((0x4000 * (n)) + 0x19ac) +#define EQ11 (n) ((0x4000 * (n)) + 0x1978) + +static u32 save_reg_address[] = { +/* Lane 0/1/2/3 Register */ +DIG_8 (0 ),ILL13 (0 ),DIG_10 (0 ),RST_DLY (0 ),BYP_15 (0 ),BYP_12 (0 ),MISC3 (0 ),EQ11 (0 ), +DIG_8 (1 ),ILL13 (1 ),DIG_10 (1 ),RST_DLY (1 ),BYP_15 (1 ),BYP_12 (1 ),MISC3 (1 ),EQ11 (1 ), +DIG_8 (2 ),ILL13 (2 ),DIG_10 (2 ),RST_DLY (2 ),BYP_15 (2 ),BYP_12 (2 ),MISC3 (2 ),EQ11 (2 ), +DIG_8 (3 ),ILL13 (3 ),DIG_10 (3 ),RST_DLY (3 ),BYP_15 (3 ),BYP_12 (3 ),MISC3 (3 ),EQ11 (3 ), +}; +struct xpsgtr_dev ;/**
@@ -214,6 +232,7 @@ struct xpsgtr_phy {* @tx_term_fix: fix for GT issue * @saved_icm_cfg0: stored value of ICM CFG0 register * @saved_icm_cfg1: stored value of ICM CFG1 register +* @saved_regs: registers to be saved/restored during suspend/resume */ struct xpsgtr_dev {struct device *dev;
@@ -226,6 +245,7 @@ struct xpsgtr_dev {bool tx_term_fix;unsigned int saved_icm_cfg0;unsigned int saved_icm_cfg1; +u32 *saved_regs; };/*
@@ -299,6 +319,32 @@ static inline void xpsgtr_clr_set_phy(struct xpsgtr_phy *gtr_phy,writel ((readl (addr) & ~clr) | set, addr); } +/** +* xpsgtr_save_lane_regs - Saves registers on suspend +* @gtr_dev: pointer to phy controller context structure +*/ +static void xpsgtr_save_lane_regs (struct xpsgtr_dev *gtr_dev) +{ +int i; + +for (i =0 ; i <ARRAY_SIZE (save_reg_address); i++) + gtr_dev->saved_regs[i] =xpsgtr_read (gtr_dev, + save_reg_address[i]); +} + +/** +* xpsgtr_restore_lane_regs - Restores registers on resume +* @gtr_dev: pointer to phy controller context structure +*/ +static void xpsgtr_restore_lane_regs (struct xpsgtr_dev *gtr_dev) +{ +int i; + +for (i =0 ; i <ARRAY_SIZE (save_reg_address); i++) +xpsgtr_write (gtr_dev, save_reg_address[i], + gtr_dev->saved_regs[i]); +} +/* * Hardware Configuration */
@@ -838,6 +884,8 @@ static int xpsgtr_runtime_suspend(struct device *dev) gtr_dev->saved_icm_cfg0 =xpsgtr_read (gtr_dev,ICM_CFG0 ); gtr_dev->saved_icm_cfg1 =xpsgtr_read (gtr_dev,ICM_CFG1 ); +xpsgtr_save_lane_regs (gtr_dev); +return 0 ; }
@@ -848,6 +896,8 @@ static int xpsgtr_runtime_resume(struct device *dev)unsigned int i;bool skip_phy_init; +xpsgtr_restore_lane_regs (gtr_dev); + icm_cfg0 =xpsgtr_read (gtr_dev,ICM_CFG0 ); icm_cfg1 =xpsgtr_read (gtr_dev,ICM_CFG1 );
@@ -990,6 +1040,12 @@ static int xpsgtr_probe(struct platform_device *pdev)return ret; } + gtr_dev->saved_regs =devm_kmalloc (gtr_dev->dev, +sizeof (save_reg_address), +GFP_KERNEL ); +if (!gtr_dev->saved_regs) +return -ENOMEM ; +return 0 ; }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 195/215 dmaengine: dw: Add peripheral bus width verification
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Serge Semin <[email protected]>
[ Upstream commit b336268dde75cb09bd795cb24893d52152a9191f ]
Currently the src_addr_width and dst_addr_width fields of the dma_slave_config structure are mapped to the CTLx.SRC_TR_WIDTH and CTLx.DST_TR_WIDTH fields of the peripheral bus side in order to have the properly aligned data passed to the target device. It's done just by converting the passed peripheral bus width to the encoded value using the __ffs() function. This implementation has several problematic sides:
1. __ffs() is undefined if no bit exist in the passed value. Thus if the specified addr-width is DMA_SLAVE_BUSWIDTH_UNDEFINED, __ffs() may return unexpected value depending on the platform-specific implementation.
2. DW AHB DMA-engine permits having the power-of-2 transfer width limited by the DMAH_Mk_HDATA_WIDTH IP-core synthesize parameter. Specifying bus-width out of that constraints scope will definitely cause unexpected result since the destination reg will be only partly touched than the client driver implied.
Let's fix all of that by adding the peripheral bus width verification method and calling it in dwc_config() which is supposed to be executed before preparing any transfer. The new method will make sure that the passed source or destination address width is valid and if undefined then the driver will just fallback to the 1-byte width transfer.
--- drivers/dma/dw/core.c | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+)
drivers/dma/dw/core.c +38 -0
@@ -16,6 +16,7 @@#include <linux/init.h> #include <linux/interrupt.h> #include <linux/io.h> +#include <linux/log2.h> #include <linux/mm.h> #include <linux/module.h> #include <linux/slab.h>
@@ -783,10 +784,43 @@ bool dw_dma_filter(struct dma_chan *chan, void *param) }EXPORT_SYMBOL_GPL (dw_dma_filter); +static int dwc_verify_p_buswidth (struct dma_chan *chan) +{ +struct dw_dma_chan *dwc =to_dw_dma_chan (chan); +struct dw_dma *dw =to_dw_dma (chan->device); +u32 reg_width, max_width; + +if (dwc->dma_sconfig.direction ==DMA_MEM_TO_DEV ) + reg_width = dwc->dma_sconfig.dst_addr_width; +else if (dwc->dma_sconfig.direction ==DMA_DEV_TO_MEM ) + reg_width = dwc->dma_sconfig.src_addr_width; +else /* DMA_MEM_TO_MEM */ +return 0 ; + + max_width = dw->pdata->data_width[dwc->dws.p_master]; + +/* Fall-back to 1-byte transfer width if undefined */ +if (reg_width ==DMA_SLAVE_BUSWIDTH_UNDEFINED ) + reg_width =DMA_SLAVE_BUSWIDTH_1_BYTE ; +else if (!is_power_of_2 (reg_width) || reg_width > max_width) +return -EINVAL ; +else /* bus width is valid */ +return 0 ; + +/* Update undefined addr width value */ +if (dwc->dma_sconfig.direction ==DMA_MEM_TO_DEV ) + dwc->dma_sconfig.dst_addr_width = reg_width; +else /* DMA_DEV_TO_MEM */ + dwc->dma_sconfig.src_addr_width = reg_width; + +return 0 ; +} +static int dwc_config (struct dma_chan *chan,struct dma_slave_config *sconfig) {struct dw_dma_chan *dwc =to_dw_dma_chan (chan);struct dw_dma *dw =to_dw_dma (chan->device); +int ret;memcpy (&dwc->dma_sconfig, sconfig,sizeof (*sconfig));
@@ -795,6 +829,10 @@ static int dwc_config(struct dma_chan *chan, struct dma_slave_config *sconfig) dwc->dma_sconfig.dst_maxburst =clamp (dwc->dma_sconfig.dst_maxburst,0U , dwc->max_burst); + ret =dwc_verify_p_buswidth (chan); +if (ret) +return ret; + dw->encode_maxburst (dwc, &dwc->dma_sconfig.src_maxburst); dw->encode_maxburst (dwc, &dwc->dma_sconfig.dst_maxburst);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 196/215 dmaengine: dw: Add memory bus width verification
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Serge Semin <[email protected]>
[ Upstream commit d04b21bfa1c50a2ade4816cab6fdc91827b346b1 ]
Currently in case of the DEV_TO_MEM or MEM_TO_DEV DMA transfers the memory data width (single transfer width) is determined based on the buffer length, buffer base address or DMA master-channel max address width capability. It isn't enough in case of the channel disabling prior the block transfer is finished. Here is what DW AHB DMA IP-core databook says regarding the port suspension (DMA-transfer pause) implementation in the controller:
"When CTLx.SRC_TR_WIDTH < CTLx.DST_TR_WIDTH and the CFGx.CH_SUSP bit is high, the CFGx.FIFO_EMPTY is asserted once the contents of the FIFO do not permit a single word of CTLx.DST_TR_WIDTH to be formed. However, there may still be data in the channel FIFO, but not enough to form a single transfer of CTLx.DST_TR_WIDTH. In this scenario, once the channel is disabled, the remaining data in the channel FIFO is not transferred to the destination peripheral."
So in case if the port gets to be suspended and then disabled it's possible to have the data silently discarded even though the controller reported that FIFO is empty and the CTLx.BLOCK_TS indicated the dropped data already received from the source device. This looks as if the data somehow got lost on a way from the peripheral device to memory and causes problems for instance in the DW APB UART driver, which pauses and disables the DMA-transfer as soon as the recv data timeout happens. Here is the way it looks:
Memory <------- DMA FIFO <------ UART FIFO <---------------- UART
DST_TR_WIDTH -+--------| | |
| | | | No more data
Current lvl -+--------| |---------+- DMA-burst lvl
| | |---------+- Leftover data
| | |---------+- SRC_TR_WIDTH
-+--------+-------+---------+In the example above: no more data is getting received over the UART port and BLOCK_TS is not even close to be fully received; some data is left in the UART FIFO, but not enough to perform a bursted DMA-xfer to the DMA FIFO; some data is left in the DMA FIFO, but not enough to be passed further to the system memory in a single transfer. In this situation the 8250 UART driver catches the recv timeout interrupt, pauses the DMA-transfer and terminates it completely, after which the IRQ handler manually fetches the leftover data from the UART FIFO into the recv-buffer. But since the DMA-channel has been disabled with the data left in the DMA FIFO, that data will be just discarded and the recv-buffer will have a gap of the "current lvl" size in the recv-buffer at the tail of the lately received data portion. So the data will be lost just due to the misconfigured DMA transfer.
Note this is only relevant for the case of the transfer suspension and _disabling_. No problem will happen if the transfer will be re-enabled afterwards or the block transfer is fully completed. In the later case the "FIFO flush mode" will be executed at the transfer final stage in order to push out the data left in the DMA FIFO.
In order to fix the denoted problem the DW AHB DMA-engine driver needs to make sure that the _bursted_ source transfer width is greater or equal to the single destination transfer (note the HW databook describes more strict constraint than actually required). Since the peripheral-device side is prescribed by the client driver logic, the memory-side can be only used for that. The solution can be easily implemented for the DEV_TO_MEM transfers just by adjusting the memory-channel address width. Sadly it's not that easy for the MEM_TO_DEV transfers since the mem-to-dma burst size is normally dynamically determined by the controller. So the only thing that can be done is to make sure that memory-side address width is greater than the peripheral device address width.
--- drivers/dma/dw/core.c | 51 +++++++++++++++++++++++++++++++++++++------ 1 file changed, 44 insertions(+), 7 deletions(-)
drivers/dma/dw/core.c +44 -7
@@ -625,12 +625,10 @@ dwc_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,struct dw_desc *prev;struct dw_desc *first;u32 ctllo, ctlhi; -u8 m_master = dwc->dws.m_master; -u8 lms =DWC_LLP_LMS (m_master); +u8 lms =DWC_LLP_LMS (dwc->dws.m_master);dma_addr_t reg;unsigned int reg_width;unsigned int mem_width; -unsigned int data_width = dw->pdata->data_width[m_master];unsigned int i;struct scatterlist *sg;size_t total_len =0 ;
@@ -664,7 +662,7 @@ dwc_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl, mem =sg_dma_address (sg); len =sg_dma_len (sg); - mem_width =__ffs (data_width | mem | len); + mem_width =__ffs (sconfig->src_addr_width | mem | len); slave_sg_todev_fill_desc: desc =dwc_desc_get (dwc);
@@ -724,7 +722,7 @@ dwc_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,lli_write (desc, sar, reg);lli_write (desc, dar, mem);lli_write (desc, ctlhi, ctlhi); - mem_width =__ffs (data_width | mem); + mem_width =__ffs (sconfig->dst_addr_width | mem);lli_write (desc, ctllo, ctllo |DWC_CTLL_DST_WIDTH (mem_width)); desc->len = dlen;
@@ -816,6 +814,41 @@ static int dwc_verify_p_buswidth(struct dma_chan *chan)return 0 ; } +static int dwc_verify_m_buswidth (struct dma_chan *chan) +{ +struct dw_dma_chan *dwc =to_dw_dma_chan (chan); +struct dw_dma *dw =to_dw_dma (chan->device); +u32 reg_width, reg_burst, mem_width; + + mem_width = dw->pdata->data_width[dwc->dws.m_master]; + +/* +* It's possible to have a data portion locked in the DMA FIFO in case +* of the channel suspension. Subsequent channel disabling will cause +* that data silent loss. In order to prevent that maintain the src and +* dst transfer widths coherency by means of the relation: +* (CTLx.SRC_TR_WIDTH * CTLx.SRC_MSIZE >= CTLx.DST_TR_WIDTH) +* Look for the details in the commit message that brings this change. +* +* Note the DMA configs utilized in the calculations below must have +* been verified to have correct values by this method call. +*/ +if (dwc->dma_sconfig.direction ==DMA_MEM_TO_DEV ) { + reg_width = dwc->dma_sconfig.dst_addr_width; +if (mem_width < reg_width) +return -EINVAL ; + + dwc->dma_sconfig.src_addr_width = mem_width; + }else if (dwc->dma_sconfig.direction ==DMA_DEV_TO_MEM ) { + reg_width = dwc->dma_sconfig.src_addr_width; + reg_burst =rounddown_pow_of_two (dwc->dma_sconfig.src_maxburst); + + dwc->dma_sconfig.dst_addr_width =min (mem_width, reg_width * reg_burst); + } + +return 0 ; +} +static int dwc_config (struct dma_chan *chan,struct dma_slave_config *sconfig) {struct dw_dma_chan *dwc =to_dw_dma_chan (chan);
@@ -825,14 +858,18 @@ static int dwc_config(struct dma_chan *chan, struct dma_slave_config *sconfig)memcpy (&dwc->dma_sconfig, sconfig,sizeof (*sconfig)); dwc->dma_sconfig.src_maxburst = -clamp (dwc->dma_sconfig.src_maxburst,0U , dwc->max_burst); +clamp (dwc->dma_sconfig.src_maxburst,1U , dwc->max_burst); dwc->dma_sconfig.dst_maxburst = -clamp (dwc->dma_sconfig.dst_maxburst,0U , dwc->max_burst); +clamp (dwc->dma_sconfig.dst_maxburst,1U , dwc->max_burst); ret =dwc_verify_p_buswidth (chan);if (ret)return ret; + ret =dwc_verify_m_buswidth (chan); +if (ret) +return ret; + dw->encode_maxburst (dwc, &dwc->dma_sconfig.src_maxburst); dw->encode_maxburst (dwc, &dwc->dma_sconfig.dst_maxburst);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 197/215 ethtool: check device is present when getting link settings
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jamie Bainbridge <[email protected]>
[ Upstream commit a699781c79ecf6cfe67fb00a0331b4088c7c8466 ]
A sysfs reader can race with a device reset or removal, attempting to read device state when the device is not actually present. eg:
[exception RIP: qed_get_current_link+17]
#8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede] #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3
#10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4 #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300
#12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c
#13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3
#15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1
#16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f
#17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb
crash> struct net_device.state ffff9a9d21336000
state = 5,
state 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100). The device is not present, note lack of __LINK_STATE_PRESENT (0b10).
This is the same sort of panic as observed in commit 4224cfd7fb65 ("net-sysfs: add check for netdevice being present to speed_show").
There are many other callers of __ethtool_get_link_ksettings() which don't have a device presence check.
Move this check into ethtool to protect all callers.
--- net/core/net-sysfs.c | 2 +- net/ethtool/ioctl.c | 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-)
net/core/net-sysfs.c +1 -1
@@ -214,7 +214,7 @@ static ssize_t speed_show(struct device *dev,if (!rtnl_trylock ())return restart_syscall (); -if (netif_running (netdev) &&netif_device_present (netdev)) { +if (netif_running (netdev)) {struct ethtool_link_ksettings cmd;if (!__ethtool_get_link_ksettings (netdev, &cmd))
net/ethtool/ioctl.c +3 -0
@@ -433,6 +433,9 @@ int __ethtool_get_link_ksettings(struct net_device *dev,if (!dev->ethtool_ops->get_link_ksettings)return -EOPNOTSUPP ; +if (!netif_device_present (dev)) +return -ENODEV ; +memset (link_ksettings,0 ,sizeof (*link_ksettings));return dev->ethtool_ops->get_link_ksettings (dev, link_ksettings); }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 198/215 gtp: fix a potential NULL pointer dereference
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Cong Wang <[email protected]>
[ Upstream commit defd8b3c37b0f9cb3e0f60f47d3d78d459d57fda ]
When sockfd_lookup() fails, gtp_encap_enable_socket() returns a NULL pointer, but its callers only check for error pointers thus miss the NULL pointer case.
Fix it by returning an error pointer with the error code carried from sockfd_lookup().
(I found this bug during code inspection.)
--- drivers/net/gtp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/gtp.c +1 -1
@@ -817,7 +817,7 @@ static struct sock *gtp_encap_enable_socket(int fd, int type, sock =sockfd_lookup (fd, &err);if (!sock) {pr_debug ("gtp socket fd=%d not found\n" , fd); -return NULL ; +return ERR_PTR (err); } sk = sock->sk;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 199/215 net: busy-poll: use ktime_get_ns() instead of local_clock()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 0870b0d8b393dde53106678a1e2cec9dfa52f9b7 ]
Typically, busy-polling durations are below 100 usec.
When/if the busy-poller thread migrates to another cpu, local_clock() can be off by +/-2msec or more for small values of HZ, depending on the platform.
Use ktimer_get_ns() to ensure deterministic behavior, which is the whole point of busy-polling.
--- include/net/busy_poll.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/net/busy_poll.h +1 -1
@@ -63,7 +63,7 @@ static inline bool sk_can_busy_loop(struct sock *sk)static inline unsigned long busy_loop_current_time (void ) {#ifdef CONFIG_NET_RX_BUSY_POLL -return (unsigned long )(local_clock () >>10 ); +return (unsigned long )(ktime_get_ns () >>10 );#else return 0 ;#endif
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 200/215 nfc: pn533: Add poll mod list filling check
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aleksandr Mishin <[email protected]>
[ Upstream commit febccb39255f9df35527b88c953b2e0deae50e53 ]
In case of im_protocols value is 1 and tm_protocols value is 0 this combination successfully passes the check
'if (!im_protocols && !tm_protocols)' in the nfc_start_poll(). But then after pn533_poll_create_mod_list() call in pn533_start_poll() poll mod list will remain empty and dev->poll_mod_count will remain 0 which lead to division by zero.
Normally no im protocol has value 1 in the mask, so this combination is not expected by driver. But these protocol values actually come from userspace via Netlink interface (NFC_CMD_START_POLL operation). So a broken or malicious program may pass a message containing a "bad" combination of protocol parameter values so that dev->poll_mod_count is not incremented inside pn533_poll_create_mod_list(), thus leading to division by zero.
Call trace looks like:nfc_genl_start_poll()
nfc_start_poll()
->start_poll()
pn533_start_poll()Add poll mod list filling check.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
--- drivers/nfc/pn533/pn533.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/nfc/pn533/pn533.c +5 -0
@@ -1725,6 +1725,11 @@ static int pn533_start_poll(struct nfc_dev *nfc_dev, }pn533_poll_create_mod_list (dev, im_protocols, tm_protocols); +if (!dev->poll_mod_count) { +nfc_err (dev->dev, +"Poll mod list is empty\n" ); +return -EINVAL ; + }/* Do not always start polling from the same modulation */ get_random_bytes (&rand_mod,sizeof (rand_mod));
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 201/215 soc: qcom: cmd-db: Map shared memory as WC, not WB
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Volodymyr Babchuk <[email protected]>
commit f9bb896eab221618927ae6a2f1d566567999839d upstream.
Linux does not write into cmd-db region. This region of memory is write protected by XPU. XPU may sometime falsely detect clean cache eviction as "write" into the write protected region leading to secure interrupt which causes an endless loop somewhere in Trust Zone.
The only reason it is working right now is because Qualcomm Hypervisor maps the same region as Non-Cacheable memory in Stage 2 translation tables. The issue manifests if we want to use another hypervisor (like Xen or KVM), which does not know anything about those specific mappings.
Changing the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC removes dependency on correct mappings in Stage 2 tables. This patch fixes the issue by updating the mapping to MEMREMAP_WC.
I tested this on SA8155P with Xen.
--- drivers/soc/qcom/cmd-db.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/soc/qcom/cmd-db.c +1 -1
@@ -350,7 +350,7 @@ static int cmd_db_dev_probe(struct platfreturn -EINVAL ; } - cmd_db_header =memremap (rmem->base, rmem->size,MEMREMAP_WB ); + cmd_db_header =memremap (rmem->base, rmem->size,MEMREMAP_WC );if (!cmd_db_header) { ret = -ENOMEM ; cmd_db_header =NULL ;
Greg Kroah-Hartman
maintainerPATCH 202/215 cdc-acm: Add DISABLE_ECHO quirk for GE HealthCare UI Controller
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ian Ray <[email protected]>
commit 0b00583ecacb0b51712a5ecd34cf7e6684307c67 upstream.
USB_DEVICE(0x1901, 0x0006) may send data before cdc_acm is ready, which may be misinterpreted in the default N_TTY line discipline.
--- drivers/usb/class/cdc-acm.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/usb/class/cdc-acm.c +3 -0
@@ -1741,6 +1741,9 @@ static const struct usb_device_id acm_id { USB_DEVICE(0x11ca, 0x0201), /* VeriFone Mx870 Gadget Serial */ .driver_info =SINGLE_RX_URB , }, + { USB_DEVICE(0x1901, 0x0006), /* GE Healthcare Patient Monitor UI Controller */ + .driver_info = DISABLE_ECHO, /* DISABLE ECHO in termios flag */ + }, { USB_DEVICE(0x1965, 0x0018), /* Uniden UBC125XLT */ .driver_info = NO_UNION_NORMAL, /* has no union descriptor */ },
Greg Kroah-Hartman
maintainerPATCH 203/215 USB: serial: option: add MeiG Smart SRM825L
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: ZHANG Yuntian <[email protected]>
commit 9a471de516c35219d1722c13367191ce1f120fe9 upstream.
Add support for MeiG Smart SRM825L which is based on Qualcomm 315 chip.
T: Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0 D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 P: Vendor=2dee ProdID=4d22 Rev= 4.14 S: Manufacturer=MEIG S: Product=LTE-A Module S: SerialNumber=6f345e48 C:* #Ifs= 6 Cfg#= 1 Atr=80 MxPwr=896mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=84(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=05(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=88(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan E: Ad=89(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
--- drivers/usb/serial/option.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/usb/serial/option.c +5 -0
@@ -619,6 +619,8 @@ static void option_instat_callback(struc/* MeiG Smart Technology products */ #define MEIGSMART_VENDOR_ID 0x2dee +/* MeiG Smart SRM825L based on Qualcomm 315 */ +#define MEIGSMART_PRODUCT_SRM825L 0x4d22/* MeiG Smart SLM320 based on UNISOC UIS8910 */ #define MEIGSMART_PRODUCT_SLM320 0x4d41
@@ -2366,6 +2368,9 @@ static const struct usb_device_id option { USB_DEVICE_AND_INTERFACE_INFO(UNISOC_VENDOR_ID, TOZED_PRODUCT_LT70C, 0xff, 0, 0) }, { USB_DEVICE_AND_INTERFACE_INFO(UNISOC_VENDOR_ID, LUAT_PRODUCT_AIR720U, 0xff, 0, 0) }, { USB_DEVICE_AND_INTERFACE_INFO(MEIGSMART_VENDOR_ID, MEIGSMART_PRODUCT_SLM320, 0xff, 0, 0) }, + { USB_DEVICE_AND_INTERFACE_INFO(MEIGSMART_VENDOR_ID, MEIGSMART_PRODUCT_SRM825L, 0xff, 0xff, 0x30) }, + { USB_DEVICE_AND_INTERFACE_INFO(MEIGSMART_VENDOR_ID, MEIGSMART_PRODUCT_SRM825L, 0xff, 0xff, 0x40) }, + { USB_DEVICE_AND_INTERFACE_INFO(MEIGSMART_VENDOR_ID, MEIGSMART_PRODUCT_SRM825L, 0xff, 0xff, 0x60) }, { } /* Terminating entry */ };MODULE_DEVICE_TABLE (usb, option_ids);
Greg Kroah-Hartman
maintainerPATCH 204/215 usb: dwc3: omap: add missing depopulate in probe error path
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Krzysztof Kozlowski <[email protected]>
commit 2aa765a43817ec8add990f83c8e54a9a5d87aa9c upstream.
Depopulate device in probe error paths to fix leak of children resources.
--- drivers/usb/dwc3/dwc3-omap.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/usb/dwc3/dwc3-omap.c +3 -1
@@ -522,11 +522,13 @@ static int dwc3_omap_probe(struct platfoif (ret) {dev_err (dev,"failed to request IRQ #%d --> %d\n" , omap->irq, ret); - goto err1; + goto err2; }dwc3_omap_enable_irqs (omap);return 0 ; +err2: +of_platform_depopulate (dev); err1:pm_runtime_put_sync (dev);pm_runtime_disable (dev);
Greg Kroah-Hartman
maintainerPATCH 205/215 usb: dwc3: core: Prevent USB core invalid event buffer address access
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Selvarasu Ganesan <[email protected]>
commit 14e497183df28c006603cc67fd3797a537eef7b9 upstream.
This commit addresses an issue where the USB core could access an invalid event buffer address during runtime suspend, potentially causing SMMU faults and other memory issues in Exynos platforms. The problem arises from the following sequence.
1. In dwc3_gadget_suspend, there is a chance of a timeout when moving the USB core to the halt state after clearing the run/stop bit by software.
2. In dwc3_core_exit, the event buffer is cleared regardless of the USB core's status, which may lead to an SMMU faults and other memory issues. if the USB core tries to access the event buffer address.
To prevent this hardware quirk on Exynos platforms, this commit ensures that the event buffer address is not cleared by software when the USB core is active during runtime suspend by checking its status before clearing the buffer address.
--- drivers/usb/dwc3/core.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/usb/dwc3/core.c +8 -0
@@ -477,9 +477,17 @@ int dwc3_event_buffers_setup(struct dwc3void dwc3_event_buffers_cleanup (struct dwc3 *dwc) {struct dwc3_event_buffer *evt; +u32 reg;if (!dwc->ev_buf)return ; +/* +* Exynos platforms may not be able to access event buffer if the +* controller failed to halt on dwc3_core_exit(). +*/ + reg =dwc3_readl (dwc->regs,DWC3_DSTS ); +if (!(reg &DWC3_DSTS_DEVCTRLHLT )) +return ; evt = dwc->ev_buf;
Greg Kroah-Hartman
maintainerPATCH 206/215 usb: dwc3: st: fix probed platform device ref count on probe error path
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Krzysztof Kozlowski <[email protected]>
commit ddfcfeba891064b88bb844208b43bef2ef970f0c upstream.
The probe function never performs any paltform device allocation, thus error path "undo_platform_dev_alloc" is entirely bogus. It drops the reference count from the platform device being probed. If error path is triggered, this will lead to unbalanced device reference counts and premature release of device resources, thus possible use-after-free when releasing remaining devm-managed resources.
--- drivers/usb/dwc3/dwc3-st.c | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-)
drivers/usb/dwc3/dwc3-st.c +3 -8
@@ -219,10 +219,8 @@ static int st_dwc3_probe(struct platform dwc3_data->regmap = regmap; res =platform_get_resource_byname (pdev,IORESOURCE_MEM ,"syscfg-reg" ); -if (!res) { - ret = -ENXIO ; - goto undo_platform_dev_alloc; - } +if (!res) +return -ENXIO ; dwc3_data->syscfg_reg_off = res->start;
@@ -233,8 +231,7 @@ static int st_dwc3_probe(struct platformdevm_reset_control_get_exclusive (dev,"powerdown" );if (IS_ERR (dwc3_data->rstc_pwrdn)) {dev_err (&pdev->dev,"could not get power controller\n" ); - ret =PTR_ERR (dwc3_data->rstc_pwrdn); - goto undo_platform_dev_alloc; +return PTR_ERR (dwc3_data->rstc_pwrdn); }/* Manage PowerDown */
@@ -300,8 +297,6 @@ undo_softreset:reset_control_assert (dwc3_data->rstc_rst); undo_powerdown:reset_control_assert (dwc3_data->rstc_pwrdn); -undo_platform_dev_alloc: -platform_device_put (pdev);return ret; }
Greg Kroah-Hartman
maintainerPATCH 207/215 usb: dwc3: st: add missing depopulate in probe error path
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Krzysztof Kozlowski <[email protected]>
commit cd4897bfd14f6a5388b21ba45a066541a0425199 upstream.
Depopulate device in probe error paths to fix leak of children resources.
--- drivers/usb/dwc3/dwc3-st.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/usb/dwc3/dwc3-st.c +4 -1
@@ -266,7 +266,7 @@ static int st_dwc3_probe(struct platformif (!child_pdev) {dev_err (dev,"failed to find dwc3 core device\n" ); ret = -ENODEV ; - goto err_node_put; + goto depopulate; } dwc3_data->dr_mode =usb_get_dr_mode (&child_pdev->dev);
@@ -282,6 +282,7 @@ static int st_dwc3_probe(struct platform ret =st_dwc3_drd_init (dwc3_data);if (ret) {dev_err (dev,"drd initialisation failed\n" ); +of_platform_depopulate (dev); goto undo_softreset; }
@@ -291,6 +292,8 @@ static int st_dwc3_probe(struct platformplatform_set_drvdata (pdev, dwc3_data);return 0 ; +depopulate: +of_platform_depopulate (dev); err_node_put:of_node_put (child); undo_softreset:
Greg Kroah-Hartman
maintainerPATCH 208/215 usb: core: sysfs: Unmerge @usb3_hardware_lpm_attr_group in remove_power_attributes()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zijun Hu <[email protected]>
commit 3a8839bbb86da7968a792123ed2296d063871a52 upstream.
Device attribute group @usb3_hardware_lpm_attr_group is merged by add_power_attributes(), but it is not unmerged explicitly, fixed by unmerging it in remove_power_attributes().
--- drivers/usb/core/sysfs.c | 1 + 1 file changed, 1 insertion(+)
drivers/usb/core/sysfs.c +1 -0
@@ -670,6 +670,7 @@ static int add_power_attributes(struct dstatic void remove_power_attributes (struct device *dev) { +sysfs_unmerge_group (&dev->kobj, &usb3_hardware_lpm_attr_group);sysfs_unmerge_group (&dev->kobj, &usb2_hardware_lpm_attr_group);sysfs_unmerge_group (&dev->kobj, &power_attr_group); }
Greg Kroah-Hartman
maintainerPATCH 209/215 usb: cdnsp: fix incorrect index in cdnsp_get_hw_deq function
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pawel Laszczak <[email protected]>
commit 0497a356d3c498221eb0c1edc1e8985816092f12 upstream.
Patch fixes the incorrect "stream_id" table index instead of "ep_index" used in cdnsp_get_hw_deq function.
--- drivers/usb/cdns3/cdnsp-ring.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/cdns3/cdnsp-ring.c +1 -1
@@ -402,7 +402,7 @@ static u64 cdnsp_get_hw_deq(struct cdnspstruct cdnsp_stream_ctx *st_ctx;struct cdnsp_ep *pep; - pep = &pdev->eps[stream_id]; + pep = &pdev->eps[ep_index];if (pep->ep_state &EP_HAS_STREAMS ) { st_ctx = &pep->stream_info.stream_ctx_array[stream_id];
Greg Kroah-Hartman
maintainerPATCH 210/215 usb: cdnsp: fix for Link TRB with TC
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pawel Laszczak <[email protected]>
commit 740f2e2791b98e47288b3814c83a3f566518fed2 upstream.
Stop Endpoint command on LINK TRB with TC bit set to 1 causes that internal cycle bit can have incorrect state after command complete. In consequence empty transfer ring can be incorrectly detected when EP is resumed.
NOP TRB before LINK TRB avoid such scenario. Stop Endpoint command is then on NOP TRB and internal cycle bit is not changed and have correct value.
--- drivers/usb/cdns3/cdnsp-gadget.h | 3 +++ drivers/usb/cdns3/cdnsp-ring.c | 28 ++++++++++++++++++++++++++++ 2 files changed, 31 insertions(+)
drivers/usb/cdns3/cdnsp-gadget.h +3 -0
@@ -811,6 +811,7 @@ struct cdnsp_stream_info {* generate Missed Service Error Event. * Set skip flag when receive a Missed Service Error Event and * process the missed tds on the endpoint ring. +* @wa1_nop_trb: hold pointer to NOP trb. */ struct cdnsp_ep {struct usb_ep endpoint;
@@ -838,6 +839,8 @@ struct cdnsp_ep {#define EP_UNCONFIGURED BIT(7)bool skip; +union cdnsp_trb *wa1_nop_trb; + };/**
drivers/usb/cdns3/cdnsp-ring.c +28 -0
@@ -1903,6 +1903,23 @@ int cdnsp_queue_bulk_tx(struct cdnsp_devreturn ret;/* +* workaround 1: STOP EP command on LINK TRB with TC bit set to 1 +* causes that internal cycle bit can have incorrect state after +* command complete. In consequence empty transfer ring can be +* incorrectly detected when EP is resumed. +* NOP TRB before LINK TRB avoid such scenario. STOP EP command is +* then on NOP TRB and internal cycle bit is not changed and have +* correct value. +*/ +if (pep->wa1_nop_trb) { + field =le32_to_cpu (pep->wa1_nop_trb->trans_event.flags); + field ^=TRB_CYCLE ; + + pep->wa1_nop_trb->trans_event.flags =cpu_to_le32 (field); + pep->wa1_nop_trb =NULL ; + } + +/* * Don't give the first TRB to the hardware (by toggling the cycle bit) * until we've finished creating all the other TRBs. The ring's cycle * state may change as we enqueue the other TRBs, so save it too.
@@ -1997,6 +2014,17 @@ int cdnsp_queue_bulk_tx(struct cdnsp_dev send_addr = addr; } +if (cdnsp_trb_is_link (ring->enqueue +1 )) { + field =TRB_TYPE (TRB_TR_NOOP ) |TRB_IOC ; +if (!ring->cycle_state) + field |=TRB_CYCLE ; + + pep->wa1_nop_trb = ring->enqueue; + +cdnsp_queue_trb (pdev, ring,0 ,0x0 ,0x0 , +TRB_INTR_TARGET (0 ), field); + } +cdnsp_check_trb_math (preq, enqd_len); ret =cdnsp_giveback_first_trb (pdev, pep, preq->request.stream_id, start_cycle, start_trb);
Greg Kroah-Hartman
maintainerPATCH 211/215 phy: zynqmp: Enable reference clock correctly
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sean Anderson <[email protected]>
commit 687d6bccb28238fcfa65f7c1badfdfeac498c428 upstream.
Lanes can use other lanes' reference clocks, as determined by refclk. Use refclk to determine the clock to enable/disable instead of always using the lane's own reference clock. This ensures the clock selected in xpsgtr_configure_pll is the one enabled.
For the other half of the equation, always program REF_CLK_SEL even when we are selecting the lane's own clock. This ensures that Linux's idea of the reference clock matches the hardware. We use the "local" clock mux for this instead of going through the ref clock network.
--- drivers/phy/xilinx/phy-zynqmp.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-)
drivers/phy/xilinx/phy-zynqmp.c +8 -6
@@ -81,7 +81,8 @@/* Reference clock selection parameters */ #define L0_Ln_REF_CLK_SEL (n) (0x2860 + (n) * 4) -#define L0_REF_CLK_SEL_MASK 0x8f +#define L0_REF_CLK_LCL_SEL BIT(7) +#define L0_REF_CLK_SEL_MASK 0x9f/* Calibration digital logic parameters */ #define L3_TM_CALIB_DIG19 0xec4c
@@ -396,11 +397,12 @@ static void xpsgtr_configure_pll(struct PLL_FREQ_MASK, ssc->pll_ref_clk);/* Enable lane clock sharing, if required */ -if (gtr_phy->refclk != gtr_phy->lane) { -/* Lane3 Ref Clock Selection Register */ +if (gtr_phy->refclk == gtr_phy->lane) +xpsgtr_clr_set (gtr_phy->dev,L0_Ln_REF_CLK_SEL (gtr_phy->lane), +L0_REF_CLK_SEL_MASK ,L0_REF_CLK_LCL_SEL ); +else xpsgtr_clr_set (gtr_phy->dev,L0_Ln_REF_CLK_SEL (gtr_phy->lane),L0_REF_CLK_SEL_MASK ,1 << gtr_phy->refclk); - }/* SSC step size [7:0] */ xpsgtr_clr_set_phy(gtr_phy, L0_PLL_SS_STEP_SIZE_0_LSB,
@@ -620,7 +622,7 @@ static int xpsgtr_phy_init(struct phy *pmutex_lock (>r_dev->gtr_mutex);/* Configure and enable the clock when peripheral phy_init call */ -if (clk_prepare_enable (gtr_dev->clk[gtr_phy->lane])) +if (clk_prepare_enable (gtr_dev->clk[gtr_phy->refclk])) goto out;/* Skip initialization if not required. */
@@ -672,7 +674,7 @@ static int xpsgtr_phy_exit(struct phy *p gtr_phy->skip_phy_init = false;/* Ensure that disable clock only, which configure for lane */ -clk_disable_unprepare (gtr_dev->clk[gtr_phy->lane]); +clk_disable_unprepare (gtr_dev->clk[gtr_phy->refclk]);return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 212/215 igc: Fix reset adapter logics when tx mode change
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Faizal Rahim <[email protected]>
commit 0afeaeb5dae86aceded0d5f0c3a54d27858c0c6f upstream.
Following the "igc: Fix TX Hang issue when QBV Gate is close" changes, remaining issues with the reset adapter logic in igc_tsn_offload_apply() have been observed:
1. The reset adapter logics for i225 and i226 differ, although they should be the same according to the guidelines in I225/6 HW Design Section 7.5.2.1 on software initialization during tx mode changes.
2. The i225 resets adapter every time, even though tx mode doesn't change. This occurs solely based on the condition igc_is_device_id_i225() when calling schedule_work().
3. i226 doesn't reset adapter for tsn->legacy tx mode changes. It only resets adapter for legacy->tsn tx mode transitions.
4. qbv_count introduced in the patch is actually not needed; in this context, a non-zero value of qbv_count is used to indicate if tx mode was unconditionally set to tsn in igc_tsn_enable_offload(). This could be replaced by checking the existing register IGC_TQAVCTRL_TRANSMIT_MODE_TSN bit.
This patch resolves all issues and enters schedule_work() to reset the adapter only when changing tx mode. It also removes reliance on qbv_count.
qbv_count field will be removed in a future patch.
Test ran:
1. Verify reset adapter behaviour in i225/6:
a) Enrol a new GCL
Reset adapter observed (tx mode change legacy->tsn)
b) Enrol a new GCL without deleting qdisc
No reset adapter observed (tx mode remain tsn->tsn)
c) Delete qdisc
Reset adapter observed (tx mode change tsn->legacy)2. Tested scenario from "igc: Fix TX Hang issue when QBV Gate is closed" to confirm it remains resolved.
[ Only want the igc_tsn_is_tx_mode_in_tsn() portion of this for older stable
kernels - gregkh ]
--- drivers/net/ethernet/intel/igc/igc_tsn.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/net/ethernet/intel/igc/igc_tsn.c +7 -0
@@ -49,6 +49,13 @@ static unsigned int igc_tsn_new_flags(streturn new_flags; } +static bool igc_tsn_is_tx_mode_in_tsn (struct igc_adapter *adapter) +{ +struct igc_hw *hw = &adapter->hw; + +return !!(rd32 (IGC_TQAVCTRL ) &IGC_TQAVCTRL_TRANSMIT_MODE_TSN ); +} +void igc_tsn_adjust_txtime_offset (struct igc_adapter *adapter) {struct igc_hw *hw = &adapter->hw;
Greg Kroah-Hartman
maintainerPATCH 213/215 igc: Fix qbv tx latency by setting gtxoffset
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Faizal Rahim <[email protected]>
commit 6c3fc0b1c3d073bd6fc3bf43dbd0e64240537464 upstream.
A large tx latency issue was discovered during testing when only QBV was enabled. The issue occurs because gtxoffset was not set when QBV is active, it was only set when launch time is active.
The patch "igc: Correct the launchtime offset" only sets gtxoffset when the launchtime_enable field is set by the user. Enabling launchtime_enable ultimately sets the register IGC_TXQCTL_QUEUE_MODE_LAUNCHT (referred to as LaunchT in the SW user manual).
Section 7.5.2.6 of the IGC i225/6 SW User Manual Rev 1.2.4 states:
"The latency between transmission scheduling (launch time) and the time the packet is transmitted to the network is listed in Table 7-61."
However, the patch misinterprets the phrase "launch time" in that section by assuming it specifically refers to the LaunchT register, whereas it actually denotes the generic term for when a packet is released from the internal buffer to the MAC transmit logic.
This launch time, as per that section, also implicitly refers to the QBV gate open time, where a packet waits in the buffer for the QBV gate to open. Therefore, latency applies whenever QBV is in use. TSN features such as QBU and QAV reuse QBV, making the latency universal to TSN features.
Discussed with i226 HW owner (Shalev, Avi) and we were in agreement that the term "launch time" used in Section 7.5.2.6 is not clear and can be easily misinterpreted. Avi will update this section to:
"When TQAVCTRL.TRANSMIT_MODE = TSN, the latency between transmission scheduling and the time the packet is transmitted to the network is listed in Table 7-61."
Fix this issue by using igc_tsn_is_tx_mode_in_tsn() as a condition to write to gtxoffset, aligning with the newly updated SW User Manual.
Tested:
1. Enrol taprio on talker board
base-time 0
cycle-time 1000000
flags 0x2
index 0 cmd S gatemask 0x1 interval1
index 0 cmd S gatemask 0x1 interval2
Note:
interval1 = interval for a 64 bytes packet to go through interval2 = cycle-time - interval1
2. Take tcpdump on listener board
3. Use udp tai app on talker to send packets to listener
4. Check the timestamp on listener via wireshark
Test Result:
100 Mbps: 113 ~193 ns
1000 Mbps: 52 ~ 84 ns
2500 Mbps: 95 ~ 223 ns
Note that the test result is similar to the patch "igc: Correct the launchtime offset".
--- drivers/net/ethernet/intel/igc/igc_tsn.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/intel/igc/igc_tsn.c +1 -1
@@ -61,7 +61,7 @@ void igc_tsn_adjust_txtime_offset(structstruct igc_hw *hw = &adapter->hw;u16 txoffset; -if (!is_any_launchtime (adapter)) +if (!igc_tsn_is_tx_mode_in_tsn (adapter))return ;switch (adapter->link_speed) {
Greg Kroah-Hartman
maintainerPATCH 214/215 scsi: aacraid: Fix double-free on probe failure
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ben Hutchings <[email protected]>
[ Upstream commit 919ddf8336f0b84c0453bac583808c9f165a85c2 ]
aac_probe_one() calls hardware-specific init functions through the aac_driver_ident::init pointer, all of which eventually call down to aac_init_adapter().
If aac_init_adapter() fails after allocating memory for aac_dev::queues, it frees the memory but does not clear that member.
After the hardware-specific init function returns an error, aac_probe_one() goes down an error path that frees the memory pointed to by aac_dev::queues, resulting.in a double-free.
--- drivers/scsi/aacraid/comminit.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/scsi/aacraid/comminit.c +2 -0
@@ -642,6 +642,7 @@ struct aac_dev *aac_init_adapter(struct aac_dev *dev)if (aac_comm_init (dev)<0 ){kfree (dev->queues); + dev->queues =NULL ;return NULL ; }/*
@@ -649,6 +650,7 @@ struct aac_dev *aac_init_adapter(struct aac_dev *dev)*/ if (aac_fib_setup (dev) <0 ) {kfree (dev->queues); + dev->queues =NULL ;return NULL ; }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 215/215 apparmor: fix policy_unpack_test on big endian systems
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guenter Roeck <[email protected]>
[ Upstream commit 98c0cc48e27e9d269a3e4db2acd72b486c88ec77 ]
policy_unpack_test fails on big endian systems because data byte order is expected to be little endian but is generated in host byte order. This results in test failures such as:
# policy_unpack_test_unpack_array_with_null_name: EXPECTATION FAILED at security/apparmor/policy_unpack_test.c:150
Expected array_size == (u16)16, but
array_size == 4096 (0x1000)
(u16)16 == 16 (0x10)
# policy_unpack_test_unpack_array_with_null_name: pass:0 fail:1 skip:0 total:1
not ok 3 policy_unpack_test_unpack_array_with_null_name
# policy_unpack_test_unpack_array_with_name: EXPECTATION FAILED at security/apparmor/policy_unpack_test.c:164
Expected array_size == (u16)16, but
array_size == 4096 (0x1000)
(u16)16 == 16 (0x10)
# policy_unpack_test_unpack_array_with_name: pass:0 fail:1 skip:0 total:1Add the missing endianness conversions when generating test data.
--- security/apparmor/policy_unpack_test.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
security/apparmor/policy_unpack_test.c +3 -3
@@ -78,14 +78,14 @@ struct aa_ext *build_aa_ext_struct(struct policy_unpack_fixture *puf, *(buf +1 ) =strlen (TEST_U32_NAME ) +1 ;strcpy (buf +3 ,TEST_U32_NAME ); *(buf +3 +strlen (TEST_U32_NAME ) +1 ) =AA_U32 ; - *((u32 *)(buf +3 +strlen (TEST_U32_NAME ) +2 )) =TEST_U32_DATA ; + *((__le32 *)(buf +3 +strlen (TEST_U32_NAME ) +2 )) =cpu_to_le32 (TEST_U32_DATA ); buf = e->start +TEST_NAMED_U64_BUF_OFFSET ; *buf =AA_NAME ; *(buf +1 ) =strlen (TEST_U64_NAME ) +1 ;strcpy (buf +3 ,TEST_U64_NAME ); *(buf +3 +strlen (TEST_U64_NAME ) +1 ) =AA_U64 ; - *((u64 *)(buf +3 +strlen (TEST_U64_NAME ) +2 )) =TEST_U64_DATA ; + *((__le64 *)(buf +3 +strlen (TEST_U64_NAME ) +2 )) =cpu_to_le64 (TEST_U64_DATA ); buf = e->start +TEST_NAMED_BLOB_BUF_OFFSET ; *buf =AA_NAME ;
@@ -101,7 +101,7 @@ struct aa_ext *build_aa_ext_struct(struct policy_unpack_fixture *puf, *(buf +1 ) =strlen (TEST_ARRAY_NAME ) +1 ;strcpy (buf +3 ,TEST_ARRAY_NAME ); *(buf +3 +strlen (TEST_ARRAY_NAME ) +1 ) =AA_ARRAY ; - *((u16 *)(buf +3 +strlen (TEST_ARRAY_NAME ) +2 )) =TEST_ARRAY_SIZE ; + *((__le16 *)(buf +3 +strlen (TEST_ARRAY_NAME ) +2 )) =cpu_to_le16 (TEST_ARRAY_SIZE );return e; }
Signature · 1 line
2.43.0
Hi Greg,
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.166 release. There are 215 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue, 03 Sep 2024 16:07:34 +0000. Anything received after that time might be too late.
No problems seen on x86_64 and aarch64 with our testing.
Thanks,
Harshit
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.166 release. There are 215 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue, 03 Sep 2024 16:07:34 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.166-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
The Powerpc defconfig builds failed on Linux stable-rc due to following build warnings / errors with clang-18 and gcc-12.
This is a same problem on current stable-rc review on
- 5.4.283-rc1 review
- 5.10.225-rc1 review
- 5.15.166-rc1 review
In the case of stable-rc linux-5.15.y
first seen on 36422b23d6d0243e79a6ddc085f8301454ea5291.
Good: v5.15.164-480-g2a66d0cb3772
BAD: v5.15.165-216-g36422b23d6d0
Anders bisected this to first bad commit id as,
fbdev: offb: replace of_node_put with __free(device_node) [ Upstream commit ce4a7ae84a58b9f33aae8d6c769b3c94f3d5ce76 ]
build log:
--------drivers/video/fbdev/offb.c:357:32: error: expected ';' at end of declaration
357 | struct device_node *pciparent
__free(device_node) = of_get_parent(dp);
| ^
| ;1 error generated.
Build Log links,
--------
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.15.y/build/v5.15.165-216-g36422b23d6d0/testrun/25000678/suite/build/test/clang-18-defconfig/log
Build failed comparison:
----------
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.15.y/build/v5.15.165-216-g36422b23d6d0/testrun/25000678/suite/build/test/clang-18-defconfig/history/
metadata:
----
git describe: v5.15.165-216-g36422b23d6d0
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git sha: 36422b23d6d0243e79a6ddc085f8301454ea5291
kernel config:
https://storage.tuxsuite.com/public/linaro/lkft/builds/2lTijUAVRaXda7PSrBQgP98ffqd/config
build url: https://storage.tuxsuite.com/public/linaro/lkft/builds/2lTijUAVRaXda7PSrBQgP98ffqd/
toolchain: clang-18 and gcc-12
config: defconfig
arch: powerpc
Steps to reproduce:
---------
- # tuxmake --runtime podman --target-arch powerpc --toolchain
clang-18 --kconfig defconfig LLVM=1 LLVM_IAS=0 LD=powerpc64le-linux-gnu-ld
--
Linaro LKFT
https://lkft.linaro.org
Greg Kroah-Hartman
maintainerQuoted 35 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.166 release. There are 215 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue, 03 Sep 2024 16:07:34 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.166-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
The Powerpc defconfig builds failed on Linux stable-rc due to following build warnings / errors with clang-18 and gcc-12.
This is a same problem on current stable-rc review on
- 5.4.283-rc1 review
- 5.10.225-rc1 review
- 5.15.166-rc1 reviewIn the case of stable-rc linux-5.15.y
first seen on
36422b23d6d0243e79a6ddc085f8301454ea5291.
Good: v5.15.164-480-g2a66d0cb3772
BAD: v5.15.165-216-g36422b23d6d0
Quoted 5 lines
Anders bisected this to first bad commit id as,
fbdev: offb: replaceof_node_putwith__free(device_node)[ Upstream commitce4a7ae84a58b9f33aae8d6c769b3c94f3d5ce76]
Now dropped, thanks.
greg k-h
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.166 release. There are 215 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue, 03 Sep 2024 16:07:34 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.166-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.166 release. There are 215 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue, 03 Sep 2024 16:07:34 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.166-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.166 release. There are 215 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Tue, 03 Sep 2024 16:07:34 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.166-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.15:
10 builds: 10 pass, 0 fail
26 boots: 26 pass, 0 fail
101 tests: 101 pass, 0 failLinux version: 5.15.166-rc1-g36422b23d6d0
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04Jon
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.166 release. There are 215 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.