* Re: [PATCH net] net: airoha: Fix memory leak in airoha_qdma_rx_process()
From: Simon Horman @ 2026-04-03 15:59 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260402-airoha_qdma_rx_process-mem-leak-fix-v1-1-b5706f402d3c@kernel.org>
On Thu, Apr 02, 2026 at 02:57:10PM +0200, Lorenzo Bianconi wrote:
> If an error occurs on the subsequents buffers belonging to the
> non-linear part of the skb (e.g. due to an error in the payload length
> reported by the NIC or if we consumed all the available fragments for
> the skb), the page_pool fragment will not be linked to the skb so it will
> not return to the pool in the airoha_qdma_rx_process() error path. Fix the
> memory leak partially reverting commit 'd6d2b0e1538d ("net: airoha: Fix
> page recycling in airoha_qdma_rx_process()")' and always running
> page_pool_put_full_page routine in the airoha_qdma_rx_process() error
> path.
>
> Fixes: d6d2b0e1538d ("net: airoha: Fix page recycling in airoha_qdma_rx_process()")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH] net: fec: make FIXED_PHY dependency unconditional
From: Simon Horman @ 2026-04-03 16:02 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Heiner Kallweit, Arnd Bergmann, netdev, linux-kernel
In-Reply-To: <20260402141048.2713445-1-arnd@kernel.org>
On Thu, Apr 02, 2026 at 04:10:40PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> When CONFIG_FIXED_PHY is in a loadable module, the fec driver cannot be
> built-in any more:
>
> x86_64-linux-ld: vmlinux.o: in function `fec_enet_mii_probe':
> fec_main.c:(.text+0xc4f367): undefined reference to `fixed_phy_unregister'
> x86_64-linux-ld: vmlinux.o: in function `fec_enet_close':
> fec_main.c:(.text+0xc59591): undefined reference to `fixed_phy_unregister'
> x86_64-linux-ld: vmlinux.o: in function `fec_enet_mii_probe.cold':
>
> Select the fixed phy support on all targets to make this build
> correctly, not just on coldfire.
>
> Notat that Essentially the stub helpers in include/linux/phy_fixed.h
> cannot be used correctly because of this build time dependency,
> and we could just remove them to hit the build failure more often
> when a driver uses them without the 'select FIXED_PHY'.
>
> Fixes: dc86b621e1b4 ("net: fec: register a fixed phy using fixed_phy_register_100fd if needed")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> I sent the same fix for B44 earlier, see commit 3f0f591b44b0 ("net: b44:
> always select CONFIG_FIXED_PHY"). I checked that there are no other
> conditional users of FIXED_PHY this time.
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* [PATCH net v2] net/sched: cls_fw: fix NULL dereference of "old" filters before change()
From: Davide Caratti @ 2026-04-03 16:04 UTC (permalink / raw)
To: Jamal Hadi Salim, Jiri Pirko, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Xiang Mei, netdev
Cc: Victor Nogueira
Like pointed out by Sashiko [1], TC filters are added to a shared block
before their ->change() function is called. This is a problem for cls_fw:
an invalid filter created with the "old" method can still classify some
packets before it is destroyed by the validation logic added by Xiang.
Therefore, insisting with repeated runs of the following script:
# ip link add dev crash0 type dummy
# ip link set dev crash0 up
# mausezahn crash0 -c 100000 -P 10 \
> -A 4.3.2.1 -B 1.2.3.4 -t udp "dp=1234" -q &
# sleep 1
# tc qdisc add dev crash0 egress_block 1 clsact
# tc filter add block 1 protocol ip prio 1 matchall \
> action skbedit mark 65536 continue
# tc filter add block 1 protocol ip prio 2 fw
# ip link del dev crash0
can still make fw_classify() hit the WARN_ON() in [2]:
WARNING: ./include/net/pkt_cls.h:88 at fw_classify+0x244/0x250 [cls_fw], CPU#18: mausezahn/1399
Modules linked in: cls_fw(E) act_skbedit(E)
CPU: 18 UID: 0 PID: 1399 Comm: mausezahn Tainted: G E 7.0.0-rc6-virtme #17 PREEMPT(full)
Tainted: [E]=UNSIGNED_MODULE
Hardware name: Red Hat KVM, BIOS 1.16.3-2.el9 04/01/2014
RIP: 0010:fw_classify+0x244/0x250 [cls_fw]
Code: 5c 49 c7 45 00 00 00 00 00 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 5b b8 ff ff ff ff 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 90 <0f> 0b 90 eb a0 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90
RSP: 0018:ffffd1b7026bf8a8 EFLAGS: 00010202
RAX: ffff8c5ac9c60800 RBX: ffff8c5ac99322c0 RCX: 0000000000000004
RDX: 0000000000000001 RSI: ffff8c5b74d7a000 RDI: ffff8c5ac8284f40
RBP: ffffd1b7026bf8d0 R08: 0000000000000000 R09: ffffd1b7026bf9b0
R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000010000
R13: ffffd1b7026bf930 R14: ffff8c5ac8284f40 R15: 0000000000000000
FS: 00007fca40c37740(0000) GS:ffff8c5b74d7a000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fca40e822a0 CR3: 0000000005ca0001 CR4: 0000000000172ef0
Call Trace:
<TASK>
tcf_classify+0x17d/0x5c0
tc_run+0x9d/0x150
__dev_queue_xmit+0x2ab/0x14d0
ip_finish_output2+0x340/0x8f0
ip_output+0xa4/0x250
raw_sendmsg+0x147d/0x14b0
__sys_sendto+0x1cc/0x1f0
__x64_sys_sendto+0x24/0x30
do_syscall_64+0x126/0xf80
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fca40e822ba
Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89
RSP: 002b:00007ffc248a42c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 000055ef233289d0 RCX: 00007fca40e822ba
RDX: 000000000000001e RSI: 000055ef23328c30 RDI: 0000000000000003
RBP: 000055ef233289d0 R08: 00007ffc248a42d0 R09: 0000000000000010
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001e
R13: 00000000000186a0 R14: 0000000000000000 R15: 00007fca41043000
</TASK>
irq event stamp: 1045778
hardirqs last enabled at (1045784): [<ffffffff864ec042>] __up_console_sem+0x52/0x60
hardirqs last disabled at (1045789): [<ffffffff864ec027>] __up_console_sem+0x37/0x60
softirqs last enabled at (1045426): [<ffffffff874d48c7>] __alloc_skb+0x207/0x260
softirqs last disabled at (1045434): [<ffffffff874fe8f8>] __dev_queue_xmit+0x78/0x14d0
Then, because of the value in the packet's mark, dereference on 'q->handle'
with NULL 'q' occurs:
BUG: kernel NULL pointer dereference, address: 0000000000000038
[...]
RIP: 0010:fw_classify+0x1fe/0x250 [cls_fw]
[...]
Skip "old-style" classification on shared blocks, so that the NULL
dereference is fixed and WARN_ON() is not hit anymore in the short
lifetime of invalid cls_fw "old-style" filters.
V2: avoid NULL dereference without hitting WARN_ON() anymore (Sashiko)
[1] https://sashiko.dev/#/patchset/20260331050217.504278-1-xmei5%40asu.edu
[2] https://elixir.bootlin.com/linux/v7.0-rc6/source/include/net/pkt_cls.h#L86
Fixes: faeea8bbf6e9 ("net/sched: cls_fw: fix NULL pointer dereference on shared blocks")
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
---
net/sched/cls_fw.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/sched/cls_fw.c b/net/sched/cls_fw.c
index 23884ef8b80c..646a730dca93 100644
--- a/net/sched/cls_fw.c
+++ b/net/sched/cls_fw.c
@@ -74,9 +74,13 @@ TC_INDIRECT_SCOPE int fw_classify(struct sk_buff *skb,
}
}
} else {
- struct Qdisc *q = tcf_block_q(tp->chain->block);
+ struct Qdisc *q;
/* Old method: classify the packet using its skb mark. */
+ if (tcf_block_shared(tp->chain->block))
+ return -1;
+
+ q = tcf_block_q(tp->chain->block);
if (id && (TC_H_MAJ(id) == 0 ||
!(TC_H_MAJ(id ^ q->handle)))) {
res->classid = id;
--
2.52.0
^ permalink raw reply related
* RE: [PATCH iwl-net] ice: fix netdev allocation with max queues instead of default
From: Loktionov, Aleksandr @ 2026-04-03 16:04 UTC (permalink / raw)
To: intel-wired-lan@lists.osuosl.org, Nguyen, Anthony L
Cc: netdev@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <20260403055948.3800555-1-aleksandr.loktionov@intel.com>
> -----Original Message-----
> From: Loktionov, Aleksandr <aleksandr.loktionov@intel.com>
> Sent: Friday, April 3, 2026 8:00 AM
> To: intel-wired-lan@lists.osuosl.org; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; Loktionov, Aleksandr
> <aleksandr.loktionov@intel.com>
> Cc: netdev@vger.kernel.org
> Subject: [PATCH iwl-net] ice: fix netdev allocation with max queues
> instead of default
>
...
Good day all,
It turns out this issue was already addressed by commit
https://web.git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=c7fcd269e1e07b2aa4bb37ffce7543c340796433 ("ice: set max queues in alloc_etherdev_mqs()"),
submited about a month ago.
I missed this earlier-sorry for the noise. This patch is
therefore, obsolete and can be ignored.
Thanks,
Aleks
^ permalink raw reply
* [PATCH v2 2/5] net: qrtr: ns: Limit the maximum number of lookups
From: Manivannan Sadhasivam via B4 Relay @ 2026-04-03 16:06 UTC (permalink / raw)
To: Manivannan Sadhasivam, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman
Cc: linux-arm-msm, netdev, linux-kernel, stable,
Manivannan Sadhasivam
In-Reply-To: <20260403-qrtr-fix-v2-0-f88a14859c63@oss.qualcomm.com>
From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Current code does no bound checking on the number of lookups a client can
perform. Though the code restricts the lookups to local clients, there is
still a possibility of a malicious local client sending a flood of
NEW_LOOKUP messages over the same socket.
Fix this issue by limiting the maximum number of lookups to 64 globally.
Since the nameserver allows only atmost one local observer, this global
lookup count will ensure that the lookups stay within the limit.
Note that, limit of 64 is chosen based on the current platform
requirements. If requirement changes in the future, this limit can be
increased.
Cc: stable@vger.kernel.org
Fixes: 0c2204a4ad71 ("net: qrtr: Migrate nameservice to kernel from userspace")
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
net/qrtr/ns.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/net/qrtr/ns.c b/net/qrtr/ns.c
index 63cb5861d87a..5b08d4d4840a 100644
--- a/net/qrtr/ns.c
+++ b/net/qrtr/ns.c
@@ -22,6 +22,7 @@ static struct {
struct socket *sock;
struct sockaddr_qrtr bcast_sq;
struct list_head lookups;
+ u32 lookup_count;
struct workqueue_struct *workqueue;
struct work_struct work;
int local_node;
@@ -70,10 +71,11 @@ struct qrtr_node {
u32 server_count;
};
-/* Max server limit is chosen based on the current platform requirements. If the
- * requirement changes in the future, this value can be increased.
+/* Max server, lookup limits are chosen based on the current platform requirements.
+ * If the requirement changes in the future, these values can be increased.
*/
#define QRTR_NS_MAX_SERVERS 256
+#define QRTR_NS_MAX_LOOKUPS 64
static struct qrtr_node *node_get(unsigned int node_id)
{
@@ -433,6 +435,7 @@ static int ctrl_cmd_del_client(struct sockaddr_qrtr *from,
list_del(&lookup->li);
kfree(lookup);
+ qrtr_ns.lookup_count--;
}
/* Remove the server belonging to this port but don't broadcast
@@ -550,6 +553,11 @@ static int ctrl_cmd_new_lookup(struct sockaddr_qrtr *from,
if (from->sq_node != qrtr_ns.local_node)
return -EINVAL;
+ if (qrtr_ns.lookup_count >= QRTR_NS_MAX_LOOKUPS) {
+ pr_err_ratelimited("QRTR client node exceeds max lookup limit!\n");
+ return -ENOSPC;
+ }
+
lookup = kzalloc_obj(*lookup);
if (!lookup)
return -ENOMEM;
@@ -558,6 +566,7 @@ static int ctrl_cmd_new_lookup(struct sockaddr_qrtr *from,
lookup->service = service;
lookup->instance = instance;
list_add_tail(&lookup->li, &qrtr_ns.lookups);
+ qrtr_ns.lookup_count++;
memset(&filter, 0, sizeof(filter));
filter.service = service;
@@ -598,6 +607,7 @@ static void ctrl_cmd_del_lookup(struct sockaddr_qrtr *from,
list_del(&lookup->li);
kfree(lookup);
+ qrtr_ns.lookup_count--;
}
}
--
2.51.0
^ permalink raw reply related
* [PATCH v2 0/5] net: qrtr: ns: A bunch of fixs
From: Manivannan Sadhasivam via B4 Relay @ 2026-04-03 16:06 UTC (permalink / raw)
To: Manivannan Sadhasivam, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman
Cc: linux-arm-msm, netdev, linux-kernel, stable, Yiming Qian,
Manivannan Sadhasivam
Hi,
This series fixes a bunch of possible memory exhaustion issues in the QRTR
nameserver.
Manivannan Sadhasivam (2):
net: qrtr: ns: Limit the maximum server registration per node
net: qrtr: ns: Limit the maximum lookups per socket
net/qrtr/ns.c | 38 ++++++++++++++++++++++++++++++++++----
1 file changed, 34 insertions(+), 4 deletions(-)
--
2.51.0
---
Manivannan Sadhasivam (5):
net: qrtr: ns: Limit the maximum server registration per node
net: qrtr: ns: Limit the maximum number of lookups
net: qrtr: ns: Free the node during ctrl_cmd_bye()
net: qrtr: ns: Limit the total number of nodes
net: qrtr: ns: Fix use-after-free in driver remove()
net/qrtr/ns.c | 71 ++++++++++++++++++++++++++++++++++++++++++++++++++---------
1 file changed, 61 insertions(+), 10 deletions(-)
---
base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
change-id: 20260331-qrtr-fix-b502c26e5f46
Best regards,
--
Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v2 1/5] net: qrtr: ns: Limit the maximum server registration per node
From: Manivannan Sadhasivam via B4 Relay @ 2026-04-03 16:06 UTC (permalink / raw)
To: Manivannan Sadhasivam, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman
Cc: linux-arm-msm, netdev, linux-kernel, stable, Yiming Qian,
Manivannan Sadhasivam
In-Reply-To: <20260403-qrtr-fix-v2-0-f88a14859c63@oss.qualcomm.com>
From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Current code does no bound checking on the number of servers added per
node. A malicious client can flood NEW_SERVER messages and exhaust memory.
Fix this issue by limiting the maximum number of server registrations to
256 per node. If the NEW_SERVER message is received for an old port, then
don't restrict it as it will get replaced. While at it, also rate limit
the error messages in the failure path of qrtr_ns_worker().
Note that the limit of 256 is chosen based on the current platform
requirements. If requirement changes in the future, this limit can be
increased.
Cc: stable@vger.kernel.org
Fixes: 0c2204a4ad71 ("net: qrtr: Migrate nameservice to kernel from userspace")
Reported-by: Yiming Qian <yimingqian591@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
net/qrtr/ns.c | 26 +++++++++++++++++++++-----
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/net/qrtr/ns.c b/net/qrtr/ns.c
index 3203b2220860..63cb5861d87a 100644
--- a/net/qrtr/ns.c
+++ b/net/qrtr/ns.c
@@ -67,8 +67,14 @@ struct qrtr_server {
struct qrtr_node {
unsigned int id;
struct xarray servers;
+ u32 server_count;
};
+/* Max server limit is chosen based on the current platform requirements. If the
+ * requirement changes in the future, this value can be increased.
+ */
+#define QRTR_NS_MAX_SERVERS 256
+
static struct qrtr_node *node_get(unsigned int node_id)
{
struct qrtr_node *node;
@@ -229,6 +235,17 @@ static struct qrtr_server *server_add(unsigned int service,
if (!service || !port)
return NULL;
+ node = node_get(node_id);
+ if (!node)
+ return NULL;
+
+ /* Make sure the new servers per port are capped at the maximum value */
+ old = xa_load(&node->servers, port);
+ if (!old && node->server_count >= QRTR_NS_MAX_SERVERS) {
+ pr_err_ratelimited("QRTR client node %u exceeds max server limit!\n", node_id);
+ return NULL;
+ }
+
srv = kzalloc_obj(*srv);
if (!srv)
return NULL;
@@ -238,10 +255,6 @@ static struct qrtr_server *server_add(unsigned int service,
srv->node = node_id;
srv->port = port;
- node = node_get(node_id);
- if (!node)
- goto err;
-
/* Delete the old server on the same port */
old = xa_store(&node->servers, port, srv, GFP_KERNEL);
if (old) {
@@ -252,6 +265,8 @@ static struct qrtr_server *server_add(unsigned int service,
} else {
kfree(old);
}
+ } else {
+ node->server_count++;
}
trace_qrtr_ns_server_add(srv->service, srv->instance,
@@ -292,6 +307,7 @@ static int server_del(struct qrtr_node *node, unsigned int port, bool bcast)
}
kfree(srv);
+ node->server_count--;
return 0;
}
@@ -670,7 +686,7 @@ static void qrtr_ns_worker(struct work_struct *work)
}
if (ret < 0)
- pr_err("failed while handling packet from %d:%d",
+ pr_err_ratelimited("failed while handling packet from %d:%d",
sq.sq_node, sq.sq_port);
}
--
2.51.0
^ permalink raw reply related
* [PATCH v2 3/5] net: qrtr: ns: Free the node during ctrl_cmd_bye()
From: Manivannan Sadhasivam via B4 Relay @ 2026-04-03 16:06 UTC (permalink / raw)
To: Manivannan Sadhasivam, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman
Cc: linux-arm-msm, netdev, linux-kernel, stable,
Manivannan Sadhasivam
In-Reply-To: <20260403-qrtr-fix-v2-0-f88a14859c63@oss.qualcomm.com>
From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
A node sends the BYE packet when it is about to go down. So the nameserver
should advertise the removal of the node to all remote and local observers
and free the node finally. But currently, the nameserver doesn't free the
node memory even after processing the BYE packet. This causes the node
memory to leak.
Hence, remove the node from Xarray list and free the node memory during
both success and failure case of ctrl_cmd_bye().
Cc: stable@vger.kernel.org
Fixes: 0c2204a4ad71 ("net: qrtr: Migrate nameservice to kernel from userspace")
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
net/qrtr/ns.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/net/qrtr/ns.c b/net/qrtr/ns.c
index 5b08d4d4840a..c95014673135 100644
--- a/net/qrtr/ns.c
+++ b/net/qrtr/ns.c
@@ -359,7 +359,7 @@ static int ctrl_cmd_bye(struct sockaddr_qrtr *from)
struct qrtr_node *node;
unsigned long index;
struct kvec iv;
- int ret;
+ int ret = 0;
iv.iov_base = &pkt;
iv.iov_len = sizeof(pkt);
@@ -374,8 +374,10 @@ static int ctrl_cmd_bye(struct sockaddr_qrtr *from)
/* Advertise the removal of this client to all local servers */
local_node = node_get(qrtr_ns.local_node);
- if (!local_node)
- return 0;
+ if (!local_node) {
+ ret = 0;
+ goto delete_node;
+ }
memset(&pkt, 0, sizeof(pkt));
pkt.cmd = cpu_to_le32(QRTR_TYPE_BYE);
@@ -392,10 +394,15 @@ static int ctrl_cmd_bye(struct sockaddr_qrtr *from)
ret = kernel_sendmsg(qrtr_ns.sock, &msg, &iv, 1, sizeof(pkt));
if (ret < 0 && ret != -ENODEV) {
pr_err("failed to send bye cmd\n");
- return ret;
+ goto delete_node;
}
}
- return 0;
+
+delete_node:
+ xa_erase(&nodes, from->sq_node);
+ kfree(node);
+
+ return ret;
}
static int ctrl_cmd_del_client(struct sockaddr_qrtr *from,
--
2.51.0
^ permalink raw reply related
* [PATCH v2 4/5] net: qrtr: ns: Limit the total number of nodes
From: Manivannan Sadhasivam via B4 Relay @ 2026-04-03 16:06 UTC (permalink / raw)
To: Manivannan Sadhasivam, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman
Cc: linux-arm-msm, netdev, linux-kernel, stable,
Manivannan Sadhasivam
In-Reply-To: <20260403-qrtr-fix-v2-0-f88a14859c63@oss.qualcomm.com>
From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Currently, the nameserver doesn't limit the number of nodes it handles.
This can be an attack vector if a malicious client starts registering
random nodes, leading to memory exhaustion.
Hence, limit the maximum number of nodes to 64. Note that, limit of 64 is
chosen based on the current platform requirements. If requirement changes
in the future, this limit can be increased.
Cc: stable@vger.kernel.org
Fixes: 0c2204a4ad71 ("net: qrtr: Migrate nameservice to kernel from userspace")
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
net/qrtr/ns.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/net/qrtr/ns.c b/net/qrtr/ns.c
index c95014673135..dfb5dad9473c 100644
--- a/net/qrtr/ns.c
+++ b/net/qrtr/ns.c
@@ -71,12 +71,16 @@ struct qrtr_node {
u32 server_count;
};
-/* Max server, lookup limits are chosen based on the current platform requirements.
- * If the requirement changes in the future, these values can be increased.
+/* Max nodes, server, lookup limits are chosen based on the current platform
+ * requirements. If the requirement changes in the future, these values can be
+ * increased.
*/
+#define QRTR_NS_MAX_NODES 64
#define QRTR_NS_MAX_SERVERS 256
#define QRTR_NS_MAX_LOOKUPS 64
+static u8 node_count;
+
static struct qrtr_node *node_get(unsigned int node_id)
{
struct qrtr_node *node;
@@ -85,6 +89,11 @@ static struct qrtr_node *node_get(unsigned int node_id)
if (node)
return node;
+ if (node_count >= QRTR_NS_MAX_NODES) {
+ pr_err_ratelimited("QRTR clients exceed max node limit!\n");
+ return NULL;
+ }
+
/* If node didn't exist, allocate and insert it to the tree */
node = kzalloc_obj(*node);
if (!node)
@@ -98,6 +107,8 @@ static struct qrtr_node *node_get(unsigned int node_id)
return NULL;
}
+ node_count++;
+
return node;
}
@@ -401,6 +412,7 @@ static int ctrl_cmd_bye(struct sockaddr_qrtr *from)
delete_node:
xa_erase(&nodes, from->sq_node);
kfree(node);
+ node_count--;
return ret;
}
--
2.51.0
^ permalink raw reply related
* [PATCH v2 5/5] net: qrtr: ns: Fix use-after-free in driver remove()
From: Manivannan Sadhasivam via B4 Relay @ 2026-04-03 16:06 UTC (permalink / raw)
To: Manivannan Sadhasivam, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman
Cc: linux-arm-msm, netdev, linux-kernel, stable,
Manivannan Sadhasivam
In-Reply-To: <20260403-qrtr-fix-v2-0-f88a14859c63@oss.qualcomm.com>
From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
In the remove callback, if a packet arrives after destroy_workqueue() is
called, but before sock_release(), the qrtr_ns_data_ready() callback will
try to queue the work, causing use-after-free issue.
Fix this issue by saving the default 'sk_data_ready' callback during
qrtr_ns_init() and use it to replace the qrtr_ns_data_ready() callback at
the start of remove(). This ensures that even if a packet arrives after
destroy_workqueue(), the work struct will not be dereferenced.
Cc: stable@vger.kernel.org
Fixes: 0c2204a4ad71 ("net: qrtr: Migrate nameservice to kernel from userspace")
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
net/qrtr/ns.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/qrtr/ns.c b/net/qrtr/ns.c
index dfb5dad9473c..c62d79e03d64 100644
--- a/net/qrtr/ns.c
+++ b/net/qrtr/ns.c
@@ -25,6 +25,7 @@ static struct {
u32 lookup_count;
struct workqueue_struct *workqueue;
struct work_struct work;
+ void (*saved_data_ready)(struct sock *sk);
int local_node;
} qrtr_ns;
@@ -754,6 +755,7 @@ int qrtr_ns_init(void)
goto err_sock;
}
+ qrtr_ns.saved_data_ready = qrtr_ns.sock->sk->sk_data_ready;
qrtr_ns.sock->sk->sk_data_ready = qrtr_ns_data_ready;
sq.sq_port = QRTR_PORT_CTRL;
@@ -803,6 +805,10 @@ EXPORT_SYMBOL_GPL(qrtr_ns_init);
void qrtr_ns_remove(void)
{
+ write_lock_bh(&qrtr_ns.sock->sk->sk_callback_lock);
+ qrtr_ns.sock->sk->sk_data_ready = qrtr_ns.saved_data_ready;
+ write_unlock_bh(&qrtr_ns.sock->sk->sk_callback_lock);
+
cancel_work_sync(&qrtr_ns.work);
destroy_workqueue(qrtr_ns.workqueue);
--
2.51.0
^ permalink raw reply related
* RE: [PATCH iwl-next] ixgbe: fix ITR value overflow in adaptive interrupt throttling
From: Loktionov, Aleksandr @ 2026-04-03 16:12 UTC (permalink / raw)
To: Simon Horman
Cc: intel-wired-lan@lists.osuosl.org, Nguyen, Anthony L,
netdev@vger.kernel.org
In-Reply-To: <20260403131857.GB113102@horms.kernel.org>
> -----Original Message-----
> From: Simon Horman <horms@kernel.org>
> Sent: Friday, April 3, 2026 3:19 PM
> To: Loktionov, Aleksandr <aleksandr.loktionov@intel.com>
> Cc: intel-wired-lan@lists.osuosl.org; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; netdev@vger.kernel.org
> Subject: Re: [PATCH iwl-next] ixgbe: fix ITR value overflow in
> adaptive interrupt throttling
>
> On Fri, Mar 27, 2026 at 08:30:45AM +0100, Aleksandr Loktionov wrote:
> > ixgbe_update_itr() packs a mode flag (IXGBE_ITR_ADAPTIVE_LATENCY,
> bit
> > 7) and a usecs delay (bits [6:0]) into an unsigned int, then stores
> it
> > in ring_container->itr which is u8. Values above 0xFF wrap,
> > corrupting both the delay and the mode-flag on the next readback.
> >
> > Separate the mode bits from the usecs sub-field; clamp only the
> latter
> > to [0, IXGBE_ITR_ADAPTIVE_LATENCY - 1] via min_t(unsigned int, ...)
> so
> > overflow cannot bleed into bit 7. Add a WARN_ONCE() when the raw
> > usecs value exceeds U8_MAX so out-of-range ITR computations are
> > visible in dmesg during development and testing.
> >
> > Fixes: b4ded8327fea ("ixgbe: Update adaptive ITR algorithm")
> > Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
>
> Somehow - perhaps because there is no m/n notation present in the []
> in the subject - Patchwork has treated each patch in this series as
> it's own patch-set.
>
> And in the case of this patch, it didn't apply - I assume because in
> order to do so an earlier patch in the series needs to be present.
>
> So CI didn't run on this patch :(
Good day, Simon
I have a bunch of simple /* independent */ patches for submission every week.
Whis way you'd recommend to send them to ease /* and accelerate review */ ?
1. submit one by one
2. submit as a batch by one git command (with the same internal main ID tag internally)
3. imagine a cover latter and submit as a patch-set
Thank you
Alex
^ permalink raw reply
* Re: [PATCH net-next 0/4] net: macb: Remove dedicated IRQ handler for WoL
From: Simon Horman @ 2026-04-03 16:17 UTC (permalink / raw)
To: Kevin Hao
Cc: Nicolas Ferre, Claudiu Beznea, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, netdev
In-Reply-To: <20260328-macb-irq-v1-0-7b3e622fb46c@gmail.com>
On Sat, Mar 28, 2026 at 06:17:44PM +0800, Kevin Hao wrote:
> During debugging of a suspend/resume issue, I observed that the macb driver
> employs a dedicated IRQ handler for Wake-on-LAN (WoL) support. To my knowledge,
> no other Ethernet driver adopts this approach. This implementation unnecessarily
> complicates the suspend/resume process without providing any clear benefit.
> Instead, we can easily modify the existing IRQ handler to manage WoL events,
> avoiding any overhead in the TX/RX hot path.
>
> I am skeptical that the minor optimizations to the IRQ handler proposed in this
> patch series would yield any measurable performance improvement. However, it
> does appear that the execution time of the macb_interrupt() function is
> slightly reduced.
>
> The following data(net throughput and execution time of macb_interrupt) were
> collected from my AMD Zynqmp board using the commands:
> taskset -c 1,2,3 iperf3 -c 192.168.3.4 -t 60 -Z -P 3 -R
> cat /sys/kernel/debug/tracing/trace_stat/function0
...
For the series:
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [net-next PATCH 04/10] bitfield.h: add FIELD_WIDTH()
From: Yury Norov @ 2026-04-03 16:18 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca
Cc: David Laight, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Linus Walleij, Alvin Šipraga, Yury Norov, Rasmus Villemoes,
Russell King, netdev, linux-kernel
In-Reply-To: <CAJq09z5kMu4ANp3n2Q0C1j8TULdCKW_yPM=nN78mNupAt51YGQ@mail.gmail.com>
On Fri, Apr 03, 2026 at 11:09:30AM -0300, Luiz Angelo Daros de Luca wrote:
> Thanks David and Yuri,
>
> This patch was originally intended to reconstruct a value split across
> multiple registers. Originally:
>
> vlan4k->member =
> FIELD_GET(RTL8365MB_CVLAN_ENTRY_D0_MBR_MASK, data[0]) |
> (FIELD_GET(RTL8365MB_CVLAN_ENTRY_D2_MBR_EXT_MASK, data[2])
> << FIELD_WIDTH(RTL8365MB_CVLAN_ENTRY_D0_MBR_MASK));
>
> However, as Yuri pointed out, I can use FIELD_PREP() to align the bits
> into the final struct member without manual bitops. While less common,
> this pattern is used elsewhere (e.g., drivers/clk/clk-lmk04832.c). The
> updated approach would be:
>
> vlan4k->member =
> FIELD_PREP(RTL8365MB_CVLAN_MBR_LO_MASK,
> FIELD_GET(RTL8365MB_CVLAN_ENTRY_D0_MBR_MASK,
> data[0])) |
> FIELD_PREP(RTL8365MB_CVLAN_MBR_HI_MASK,
>
> FIELD_GET(RTL8365MB_CVLAN_ENTRY_D2_MBR_EXT_MASK, data[2]));
>
> If this use of FIELD_PREP is preferred, I will drop this FIELD_WIDTH
> patch from the series as it would no longer have any users.
Then, for relevant patches:
Suggested-by: Yury Norov <ynorov@nvidia.com> # for split fields handling
^ permalink raw reply
* RE: [PATCH iwl-net v2 1/3] idpf: fix PREEMPT_RT raw/bh spinlock nesting for async VC handling
From: Salin, Samuel @ 2026-04-03 16:24 UTC (permalink / raw)
To: Loktionov, Aleksandr, Tantilov, Emil S,
intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, Nguyen, Anthony L, Kitszel, Przemyslaw,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, bigeasy@linutronix.de,
clrkwllms@kernel.org, rostedt@goodmis.org,
linux-rt-devel@lists.linux.dev, sgzhang@google.com,
boolli@google.com, stable@vger.kernel.org
In-Reply-To: <IA3PR11MB8986B4C8A0E0BB5A14BD0400E54CA@IA3PR11MB8986.namprd11.prod.outlook.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Loktionov, Aleksandr
> Sent: Friday, March 20, 2026 12:23 AM
> To: Tantilov, Emil S <emil.s.tantilov@intel.com>; intel-wired-
> lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; andrew+netdev@lunn.ch;
> davem@davemloft.net; edumazet@google.com; kuba@kernel.org;
> pabeni@redhat.com; bigeasy@linutronix.de; clrkwllms@kernel.org;
> rostedt@goodmis.org; linux-rt-devel@lists.linux.dev; sgzhang@google.com;
> boolli@google.com; stable@vger.kernel.org
> Subject: Re: [Intel-wired-lan] [PATCH iwl-net v2 1/3] idpf: fix PREEMPT_RT
> raw/bh spinlock nesting for async VC handling
>
>
>
> > -----Original Message-----
> > From: Tantilov, Emil S <emil.s.tantilov@intel.com>
> > Sent: Thursday, March 19, 2026 10:14 PM
> > To: intel-wired-lan@lists.osuosl.org
> > Cc: netdev@vger.kernel.org; Nguyen, Anthony L
> > <anthony.l.nguyen@intel.com>; Loktionov, Aleksandr
> > <aleksandr.loktionov@intel.com>; Kitszel, Przemyslaw
> > <przemyslaw.kitszel@intel.com>; andrew+netdev@lunn.ch;
> > davem@davemloft.net; edumazet@google.com; kuba@kernel.org;
> > pabeni@redhat.com; bigeasy@linutronix.de; clrkwllms@kernel.org;
> > rostedt@goodmis.org; linux-rt-devel@lists.linux.dev;
> > sgzhang@google.com; boolli@google.com; Tantilov, Emil S
> > <emil.s.tantilov@intel.com>; stable@vger.kernel.org
> > Subject: [PATCH iwl-net v2 1/3] idpf: fix PREEMPT_RT raw/bh spinlock
> > nesting for async VC handling
> >
> > Switch from using the completion's raw spinlock to a local lock in the
> > idpf_vc_xn struct. The conversion is safe because complete/_all() are
> > called outside the lock and there is no reason to share the completion
> > lock in the current logic. This avoids invalid wait context reported
> > by the kernel due to the async handler taking BH spinlock:
> >
> > [ 805.726977] ============================= [ 805.726991] [ BUG:
> > Invalid wait context ]
> > [ 805.727006] 7.0.0-rc2-net-devq-031026+ #28 Tainted: G S OE
> > [ 805.727026] ----------------------------- [ 805.727038]
> > kworker/u261:0/572 is trying to lock:
> > [ 805.727051] ff190da6a8dbb6a0 (&vport_config-
> > >mac_filter_list_lock){+...}-{3:3}, at:
> > idpf_mac_filter_async_handler+0xe9/0x260 [idpf] [ 805.727099] other
> > info that might help us debug this:
> > [ 805.727111] context-{5:5}
> > [ 805.727119] 3 locks held by kworker/u261:0/572:
> > [ 805.727132] #0: ff190da6db3e6148 ((wq_completion)idpf-
> > 0000:83:00.0-mbx){+.+.}-{0:0}, at: process_one_work+0x4b5/0x730 [
> > 805.727163] #1: ff3c6f0a6131fe50 ((work_completion)(&(&adapter-
> > >mbx_task)->work)){+.+.}-{0:0}, at: process_one_work+0x1e5/0x730 [
> > 805.727191] #2: ff190da765190020 (&x->wait#34){+.+.}-{2:2}, at:
> > idpf_recv_mb_msg+0xc8/0x710 [idpf] [ 805.727218] stack backtrace:
> > ...
> > [ 805.727238] Workqueue: idpf-0000:83:00.0-mbx idpf_mbx_task [idpf] [
> > 805.727247] Call Trace:
> > [ 805.727249] <TASK>
> > [ 805.727251] dump_stack_lvl+0x77/0xb0 [ 805.727259]
> > __lock_acquire+0xb3b/0x2290 [ 805.727268] ?
> > __irq_work_queue_local+0x59/0x130 [ 805.727275]
> > lock_acquire+0xc6/0x2f0 [ 805.727277] ?
> > idpf_mac_filter_async_handler+0xe9/0x260 [idpf] [ 805.727284] ?
> > _printk+0x5b/0x80 [ 805.727290] _raw_spin_lock_bh+0x38/0x50 [
> > 805.727298] ? idpf_mac_filter_async_handler+0xe9/0x260 [idpf] [
> > 805.727303] idpf_mac_filter_async_handler+0xe9/0x260 [idpf] [
> > 805.727310] idpf_recv_mb_msg+0x1c8/0x710 [idpf] [ 805.727317]
> > process_one_work+0x226/0x730 [ 805.727322]
> worker_thread+0x19e/0x340
> > [ 805.727325] ? __pfx_worker_thread+0x10/0x10 [ 805.727328]
> > kthread+0xf4/0x130 [ 805.727333] ? __pfx_kthread+0x10/0x10 [
> > 805.727336] ret_from_fork+0x32c/0x410 [ 805.727345] ?
> > __pfx_kthread+0x10/0x10 [ 805.727347] ret_from_fork_asm+0x1a/0x30 [
> > 805.727354] </TASK>
> >
> > Fixes: 34c21fa894a1 ("idpf: implement virtchnl transaction manager")
> > Cc: stable@vger.kernel.org
> > Suggested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> > Reported-by: Ray Zhang <sgzhang@google.com>
> > Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
> > ---
> > drivers/net/ethernet/intel/idpf/idpf_virtchnl.c | 14 +++++---------
> > drivers/net/ethernet/intel/idpf/idpf_virtchnl.h | 5 +++--
> > 2 files changed, 8 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
> > b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
> > index 113ecfc16dd7..582e0c8e9dc0 100644
> > --- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
> > +++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
> > @@ -287,26 +287,21 @@ int idpf_send_mb_msg(struct idpf_adapter
> > *adapter, struct idpf_ctlq_info *asq,
> > return err;
> > }
> >
> > -/* API for virtchnl "transaction" support ("xn" for short).
> > - *
> > - * We are reusing the completion lock to serialize the accesses to
> > the
> > - * transaction state for simplicity, but it could be its own separate
> > synchro
> > - * as well. For now, this API is only used from within a workqueue
> > context;
> > - * raw_spin_lock() is enough.
> > - */
> > +/* API for virtchnl "transaction" support ("xn" for short). */
> > +
> > /**
> > * idpf_vc_xn_lock - Request exclusive access to vc transaction
> > * @xn: struct idpf_vc_xn* to access
> > */
> > #define idpf_vc_xn_lock(xn) \
> > - raw_spin_lock(&(xn)->completed.wait.lock)
> > + spin_lock(&(xn)->lock)
> >
> > /**
> > * idpf_vc_xn_unlock - Release exclusive access to vc transaction
> > * @xn: struct idpf_vc_xn* to access
> > */
> > #define idpf_vc_xn_unlock(xn) \
> > - raw_spin_unlock(&(xn)->completed.wait.lock)
> > + spin_unlock(&(xn)->lock)
> >
> > /**
> > * idpf_vc_xn_release_bufs - Release reference to reply buffer(s) and
> > @@ -338,6 +333,7 @@ static void idpf_vc_xn_init(struct
> > idpf_vc_xn_manager *vcxn_mngr)
> > xn->state = IDPF_VC_XN_IDLE;
> > xn->idx = i;
> > idpf_vc_xn_release_bufs(xn);
> > + spin_lock_init(&xn->lock);
> > init_completion(&xn->completed);
> > }
> >
> > diff --git a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.h
> > b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.h
> > index fe065911ad5a..6876e3ed9d1b 100644
> > --- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.h
> > +++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.h
> > @@ -42,8 +42,8 @@ typedef int (*async_vc_cb) (struct idpf_adapter *,
> > struct idpf_vc_xn *,
> > * struct idpf_vc_xn - Data structure representing virtchnl
> > transactions
> > * @completed: virtchnl event loop uses that to signal when a reply
> > is
> > * available, uses kernel completion API
> > - * @state: virtchnl event loop stores the data below, protected by
> > the
> > - * completion's lock.
> > + * @lock: protects the transaction state fields below
> > + * @state: virtchnl event loop stores the data below, protected by
> > + @lock
> > * @reply_sz: Original size of reply, may be > reply_buf.iov_len; it
> > will be
> > * truncated on its way to the receiver thread according to
> > * reply_buf.iov_len.
> > @@ -58,6 +58,7 @@ typedef int (*async_vc_cb) (struct idpf_adapter *,
> > struct idpf_vc_xn *,
> > */
> > struct idpf_vc_xn {
> > struct completion completed;
> > + spinlock_t lock;
> > enum idpf_vc_xn_state state;
> > size_t reply_sz;
> > struct kvec reply;
> > --
> > 2.37.3
>
> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Tested-by: Samuel Salin <Samuel.salin@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-net v2 2/3] idpf: improve locking around idpf_vc_xn_push_free()
From: Salin, Samuel @ 2026-04-03 16:24 UTC (permalink / raw)
To: Tantilov, Emil S, Sebastian Andrzej Siewior
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
Nguyen, Anthony L, Loktionov, Aleksandr, Kitszel, Przemyslaw,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, clrkwllms@kernel.org,
rostedt@goodmis.org, linux-rt-devel@lists.linux.dev,
sgzhang@google.com, boolli@google.com, stable@vger.kernel.org
In-Reply-To: <6c1cc71d-0b3e-4edf-84b5-a4bac52de4dd@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Tantilov, Emil S
> Sent: Monday, March 23, 2026 9:20 AM
> To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Cc: intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; Nguyen,
> Anthony L <anthony.l.nguyen@intel.com>; Loktionov, Aleksandr
> <aleksandr.loktionov@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; andrew+netdev@lunn.ch;
> davem@davemloft.net; edumazet@google.com; kuba@kernel.org;
> pabeni@redhat.com; clrkwllms@kernel.org; rostedt@goodmis.org; linux-rt-
> devel@lists.linux.dev; sgzhang@google.com; boolli@google.com;
> stable@vger.kernel.org
> Subject: Re: [Intel-wired-lan] [PATCH iwl-net v2 2/3] idpf: improve locking
> around idpf_vc_xn_push_free()
>
>
>
> On 3/20/2026 12:42 AM, Sebastian Andrzej Siewior wrote:
> > On 2026-03-19 14:13:34 [-0700], Emil Tantilov wrote:
> >> drivers/net/ethernet/intel/idpf/idpf_virtchnl.c | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
> >> b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
> >> index 582e0c8e9dc0..fbd5a15b015c 100644
> >> --- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
> >> +++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
> >> @@ -402,7 +402,9 @@ static void idpf_vc_xn_push_free(struct
> idpf_vc_xn_manager *vcxn_mngr,
> >> struct idpf_vc_xn *xn)
> >> {
> >> idpf_vc_xn_release_bufs(xn);
> >> + spin_lock_bh(&vcxn_mngr->xn_bm_lock);
> >> set_bit(xn->idx, vcxn_mngr->free_xn_bm);
> >
> > If all of your bit manipulations happen under the same lock you could
> > replace atomic set_bit()/ clear_bit() with their non-atomic counter
> > parts __set_bit()/ __clear_bit().
>
> We have taken similar approach in the refactor/move to libie:
> https://lore.kernel.org/netdev/20251117134912.18566-7-
> larysa.zaremba@intel.com/
>
> Thanks,
> Emil
>
> >
> > The lockless alternative would be find_first_bit() +
> > test_and_set_bit() loop. Probably another atomic op for salt. Using
> > the __ is free with this change.
> >
> >> + spin_unlock_bh(&vcxn_mngr->xn_bm_lock);
> >> }
> >
> > Sebastian
Tested-by: Samuel Salin <Samuel.salin@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-net v2 3/3] idpf: set the payload size before calling the async handler
From: Salin, Samuel @ 2026-04-03 16:24 UTC (permalink / raw)
To: Tantilov, Emil S, intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, Nguyen, Anthony L, Loktionov, Aleksandr,
Kitszel, Przemyslaw, andrew+netdev@lunn.ch, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
bigeasy@linutronix.de, clrkwllms@kernel.org, rostedt@goodmis.org,
linux-rt-devel@lists.linux.dev, sgzhang@google.com,
boolli@google.com, Tantilov, Emil S, stable@vger.kernel.org
In-Reply-To: <20260319211335.23236-4-emil.s.tantilov@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Emil Tantilov
> Sent: Thursday, March 19, 2026 2:14 PM
> To: intel-wired-lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; Loktionov, Aleksandr
> <aleksandr.loktionov@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; andrew+netdev@lunn.ch;
> davem@davemloft.net; edumazet@google.com; kuba@kernel.org;
> pabeni@redhat.com; bigeasy@linutronix.de; clrkwllms@kernel.org;
> rostedt@goodmis.org; linux-rt-devel@lists.linux.dev; sgzhang@google.com;
> boolli@google.com; Tantilov, Emil S <emil.s.tantilov@intel.com>;
> stable@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH iwl-net v2 3/3] idpf: set the payload size
> before calling the async handler
>
> Set the payload size before forwarding the reply to the async handler.
> Without this, xn->reply_sz will be 0 and idpf_mac_filter_async_handler() will
> never get past the size check.
>
> Fixes: 34c21fa894a1 ("idpf: implement virtchnl transaction manager")
> Cc: stable@vger.kernel.org
> Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> Reviewed-by: Li Li <boolli@google.com>
> ---
Tested-by: Samuel Salin <Samuel.salin@intel.com>
^ permalink raw reply
* Re: [PATCH net 1/1] net: sched: act_csum: validate nested VLAN headers
From: Simon Horman @ 2026-04-03 16:26 UTC (permalink / raw)
To: Ren Wei
Cc: netdev, jhs, jiri, davem, edumazet, kuba, pabeni, elibr,
yifanwucs, tomapufckgml, yuantan098, bird, enjou1224z,
caoruide123
In-Reply-To: <22df2fcb49f410203eafa5d97963dd36089f4ecf.1774892775.git.caoruide123@gmail.com>
On Thu, Apr 02, 2026 at 10:46:20PM +0800, Ren Wei wrote:
> From: Ruide Cao <caoruide123@gmail.com>
>
> tcf_csum_act() walks nested VLAN headers directly from skb->data when an
> skb still carries in-payload VLAN tags. The current code reads
> vlan->h_vlan_encapsulated_proto and then pulls VLAN_HLEN bytes without
> first ensuring that the full VLAN header is present in the linear area.
>
> If only part of an inner VLAN header is linearized, accessing
> h_vlan_encapsulated_proto reads past the linear area, and the following
> skb_pull(VLAN_HLEN) may violate skb invariants.
>
> Fix this by requiring pskb_may_pull(skb, VLAN_HLEN) before accessing and
> pulling each nested VLAN header. If the header still is not fully
> available, drop the packet through the existing error path.
>
> Fixes: 2ecba2d1e45b ("net: sched: act_csum: Fix csum calc for tagged packets")
> Reported-by: Yifan Wu <yifanwucs@gmail.com>
> Reported-by: Juefei Pu <tomapufckgml@gmail.com>
> Co-developed-by: Yuan Tan <yuantan098@gmail.com>
> Signed-off-by: Yuan Tan <yuantan098@gmail.com>
> Suggested-by: Xin Liu <bird@lzu.edu.cn>
> Tested-by: Ren Wei <enjou1224z@gmail.com>
> Signed-off-by: Ruide Cao <caoruide123@gmail.com>
> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH net] net: phy: micrel: Fix MMD register access during SPD in ksz9131_resume()
From: Russell King (Oracle) @ 2026-04-03 16:28 UTC (permalink / raw)
To: Ovidiu Panait
Cc: andrew@lunn.ch, hkallweit1@gmail.com, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, Biju Das,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <TY7P301MB1984FB759690AB12AD509CD8D35EA@TY7P301MB1984.JPNP301.PROD.OUTLOOK.COM>
On Fri, Apr 03, 2026 at 03:48:02PM +0000, Ovidiu Panait wrote:
> Hi,
>
> >
> > On Fri, Apr 03, 2026 at 11:17:38AM +0000, Ovidiu Panait wrote:
> > > During system suspend, phy_suspend() puts the PHY into Software Power-
> > Down
> > > (SPD) by setting the BMCR_PDOWN bit in MII_BMCR. According to the
> > KSZ9131
> > > datasheet, MMD register access is restricted during SPD:
> > >
> > > - Only access to the standard registers (0 through 31) is supported.
> > > - Access to MMD address spaces other than MMD address space 1 is
> > > possible if the spd_clock_gate_override bit is set.
> > > - Access to MMD address space 1 is not possible.
> > >
> > > However, ksz9131_resume() calls ksz9131_config_rgmii_delay() before
> > > kszphy_resume() clears BMCR_PDOWN. This means MMD registers are accessed
> > > while the PHY is still in SPD, contrary to the datasheet.
> > >
> > > Additionally, on platforms where the PHY loses power during suspend
> > > (e.g. RZ/G3E), all settings from ksz9131_config_init(), not just the
> > > RGMII delays, are lost and need to be restored. When the MAC driver
> > > sets mac_managed_pm (e.g. stmmac), mdio_bus_phy_resume() is skipped,
> > > so phy_init_hw() (which calls config_init to restore all PHY settings)
> > > is never invoked during resume.
> > >
> > > Fix this by replacing the RGMII delay restoration with a call to
> > > phy_init_hw(), which takes the PHY out of SPD and performs full
> > > reinitialization.
> > >
> > > Fixes: f25a7eaa897f ("net: phy: micrel: Add ksz9131_resume()")
> > > Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
> > > ---
> > > drivers/net/phy/micrel.c | 9 +++++++--
> > > 1 file changed, 7 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
> > > index 2aa1dedd21b8..4236dbf4ad6b 100644
> > > --- a/drivers/net/phy/micrel.c
> > > +++ b/drivers/net/phy/micrel.c
> > > @@ -6016,8 +6016,13 @@ static int lan8841_suspend(struct phy_device
> > *phydev)
> > >
> > > static int ksz9131_resume(struct phy_device *phydev)
> > > {
> > > - if (phydev->suspended && phy_interface_is_rgmii(phydev))
> > > - ksz9131_config_rgmii_delay(phydev);
> > > + int ret;
> > > +
> > > + if (phydev->suspended) {
> > > + ret = phy_init_hw(phydev);
> > > + if (ret)
> > > + return ret;
> > > + }
> > >
> > > return kszphy_resume(phydev);
> > > }
> >
> > mdio_bus_phy_resume():
> >
> > ret = phy_init_hw(phydev);
> > if (ret < 0)
> > return ret;
> >
> > ret = phy_resume(phydev);
> > if (ret < 0)
> > return ret;
> >
> > where phy_resume() calls your resume function.
> >
> > If a MAC driver is handling suspend/resume by setting
> > phydev->mac_managed_pm then maybe the MAC driver should also be
> > issuing phy_init_hw() before calling phy_resume() ?
> >
> > Which MAC driver are you seeing a problem with?
> >
>
> On my board the KSZ9131RNX PHY is paired to stmmac.
>
> I could add phy_init_hw() before the phylink_prepare_resume() call, which
> does the phy_resume() and remove the ksz9131_config_rgmii_delay() call from
> ksz9131_resume(), as it is not correct/complete.
Yes, I think we should add phy_init_hw() before calling phy_resume()
in phylink's prepare_resume() path to ensure that the PHY state is
the same as when the PHY is resumed via the MDIO bus. Please prepare
a patch to that end, thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* RE: [PATCH net] net: phy: micrel: Fix MMD register access during SPD in ksz9131_resume()
From: Biju Das @ 2026-04-03 16:28 UTC (permalink / raw)
To: Biju Das, Ovidiu Panait, andrew@lunn.ch, hkallweit1@gmail.com,
linux@armlinux.org.uk, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, Russell King
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <TYCPR01MB1133228575528380F6F8D1CFF865EA@TYCPR01MB11332.jpnprd01.prod.outlook.com>
Hi Ovidiu Panait,
> -----Original Message-----
> From: Biju Das <biju.das.jz@bp.renesas.com>
> > Subject: RE: [PATCH net] net: phy: micrel: Fix MMD register access
> > during SPD in ksz9131_resume()
> >
> >
> > > >
> > > > Hi,
> > > >
> > > > >
> > > > > Hi Ovidiu Panait,
> > > > >
> > > > > Thanks for the patch.
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
> > > > > > Sent: 03 April 2026 12:18
> > > > > > Subject: [PATCH net] net: phy: micrel: Fix MMD register access
> > > > > > during
> > > > > SPD in ksz9131_resume()
> > > > > >
> > > > > > During system suspend, phy_suspend() puts the PHY into
> > > > > > Software
> > > > > > Power-
> > > > > Down
> > > > > > (SPD) by setting the BMCR_PDOWN bit in MII_BMCR. According to
> > > > > > the
> > > > > KSZ9131 datasheet, MMD register
> > > > > > access is restricted during SPD:
> > > > > >
> > > > > > - Only access to the standard registers (0 through 31) is
> > > supported.
> > > > > > - Access to MMD address spaces other than MMD address space 1 is
> > > > > > possible if the spd_clock_gate_override bit is set.
> > > > > > - Access to MMD address space 1 is not possible.
> > > > > >
> > > > > > However, ksz9131_resume() calls ksz9131_config_rgmii_delay()
> > > > > > before
> > > > > > kszphy_resume() clears BMCR_PDOWN. This means MMD registers
> > > > > > are accessed
> > > > > while the PHY is still in SPD,
> > > > > > contrary to the datasheet.
> > > > >
> > > > > SPD mode: This mode is used to power down the device when it is
> > > > > not in use after power-up.
> > > > > Previous register settings are maintained during and
> > > > > following the removal of SPD.
> > > > >
> > > > > Suspend to Idle case, it is in SPD mode and the MMD register
> > > > > values are retained.
> > > > >
> > > >
> > > > On resume from s2idle, ksz9131_resume() calls
> > > ksz9131_config_rgmii_delay() which does MMD accesses,
> > > > while the PHY is in SPD. According to the datasheet, it shouldn't
> > > happen. See commit e398822c4751
> > > > ("net: phy: micrel: populate .soft_reset for KSZ9131") which fixes
> > > > the
> > > same issue.
> > >
> > > On my board, while s2idle in SPD mode, it does not hang. The
> > > datasheet does not explain the behaviour when it is SPD mode. But it
> > > states that it retains all previous register values when it is out of SPD mode.
> > >
> >
> > According to the KSZ9131 datasheet ([1]):
> >
> > 4.17.3 SOFTWARE POWER-DOWN MODE (SPD)
> > ...
> > The following remain operational during SPD:
> > MII Management Interface
> > - Only access to the standard registers (0 through 31) is supported.
> > - Access to MMD address spaces other than MMD address space 1 is
> > possible if the spd_clock_gate_override bit is set.
> > - Access to MMD address space 1 is not possible.
> >
> >
> > The spd_clock_gate_override bit is not used in the KSZ9131 driver.
> >
> > While the datasheet does not specify exactly what happens if registers
> > from an unsupported address space are accessed while the PHY is in
> > SPD, I think it is correct for the driver to not do it in the first place.
> >
> > [1]
> > https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/Product
> > Documents/DataSheets/00002841D.pd
> > f
>
> For s2idlecase: ie, PHY is in software power down state you don't need to restore MMD register, as
> exiting software power down will restore those registers.
>
> You need only restore MMD registers, when PHY loses power ie, suspend to RAM case.
I believe, You really don't need to call phy_init_hw() at all
SuspendtoRAM case: ###### ksz9131_resume 1140, software power down state is 0 (Normal mode)
SuspendtoIdle case: ###### ksz9131_resume 1940, software power down state is 1 (SPD mode)
If (phydev->suspended && Normal mode)
Restore PHY specific MMD registers.
Cheers,
Biju
^ permalink raw reply
* RE: [PATCH net] net: phy: micrel: Fix MMD register access during SPD in ksz9131_resume()
From: Biju Das @ 2026-04-03 16:30 UTC (permalink / raw)
To: Ovidiu Panait, andrew@lunn.ch, hkallweit1@gmail.com,
linux@armlinux.org.uk, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, Russell King
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <TYCPR01MB11332125932E37C2E2A124CF5865EA@TYCPR01MB11332.jpnprd01.prod.outlook.com>
> -----Original Message-----
> From: Biju Das <biju.das.jz@bp.renesas.com>
> Sent: 03 April 2026 17:29
> Subject: RE: [PATCH net] net: phy: micrel: Fix MMD register access during SPD in ksz9131_resume()
>
> Hi Ovidiu Panait,
>
> > -----Original Message-----
> > From: Biju Das <biju.das.jz@bp.renesas.com>
> > > Subject: RE: [PATCH net] net: phy: micrel: Fix MMD register access
> > > during SPD in ksz9131_resume()
> > >
> > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > >
> > > > > > Hi Ovidiu Panait,
> > > > > >
> > > > > > Thanks for the patch.
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
> > > > > > > Sent: 03 April 2026 12:18
> > > > > > > Subject: [PATCH net] net: phy: micrel: Fix MMD register
> > > > > > > access during
> > > > > > SPD in ksz9131_resume()
> > > > > > >
> > > > > > > During system suspend, phy_suspend() puts the PHY into
> > > > > > > Software
> > > > > > > Power-
> > > > > > Down
> > > > > > > (SPD) by setting the BMCR_PDOWN bit in MII_BMCR. According
> > > > > > > to the
> > > > > > KSZ9131 datasheet, MMD register
> > > > > > > access is restricted during SPD:
> > > > > > >
> > > > > > > - Only access to the standard registers (0 through 31) is
> > > > supported.
> > > > > > > - Access to MMD address spaces other than MMD address space 1 is
> > > > > > > possible if the spd_clock_gate_override bit is set.
> > > > > > > - Access to MMD address space 1 is not possible.
> > > > > > >
> > > > > > > However, ksz9131_resume() calls ksz9131_config_rgmii_delay()
> > > > > > > before
> > > > > > > kszphy_resume() clears BMCR_PDOWN. This means MMD registers
> > > > > > > are accessed
> > > > > > while the PHY is still in SPD,
> > > > > > > contrary to the datasheet.
> > > > > >
> > > > > > SPD mode: This mode is used to power down the device when it
> > > > > > is not in use after power-up.
> > > > > > Previous register settings are maintained during and
> > > > > > following the removal of SPD.
> > > > > >
> > > > > > Suspend to Idle case, it is in SPD mode and the MMD register
> > > > > > values are retained.
> > > > > >
> > > > >
> > > > > On resume from s2idle, ksz9131_resume() calls
> > > > ksz9131_config_rgmii_delay() which does MMD accesses,
> > > > > while the PHY is in SPD. According to the datasheet, it
> > > > > shouldn't
> > > > happen. See commit e398822c4751
> > > > > ("net: phy: micrel: populate .soft_reset for KSZ9131") which
> > > > > fixes the
> > > > same issue.
> > > >
> > > > On my board, while s2idle in SPD mode, it does not hang. The
> > > > datasheet does not explain the behaviour when it is SPD mode. But
> > > > it states that it retains all previous register values when it is out of SPD mode.
> > > >
> > >
> > > According to the KSZ9131 datasheet ([1]):
> > >
> > > 4.17.3 SOFTWARE POWER-DOWN MODE (SPD) ...
> > > The following remain operational during SPD:
> > > MII Management Interface
> > > - Only access to the standard registers (0 through 31) is supported.
> > > - Access to MMD address spaces other than MMD address space 1 is
> > > possible if the spd_clock_gate_override bit is set.
> > > - Access to MMD address space 1 is not possible.
> > >
> > >
> > > The spd_clock_gate_override bit is not used in the KSZ9131 driver.
> > >
> > > While the datasheet does not specify exactly what happens if registers
> > > from an unsupported address space are accessed while the PHY is in
> > > SPD, I think it is correct for the driver to not do it in the first place.
> > >
> > > [1]
> > > https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/Product
> > > Documents/DataSheets/00002841D.pd
> > > f
> >
> > For s2idlecase: ie, PHY is in software power down state you don't need to restore MMD register, as
> > exiting software power down will restore those registers.
> >
> > You need only restore MMD registers, when PHY loses power ie, suspend to RAM case.
>
>
> I believe, You really don't need to call phy_init_hw() at all
>
> SuspendtoRAM case: ###### ksz9131_resume 1140, software power down state is 0 (Normal mode)
> SuspendtoIdle case: ###### ksz9131_resume 1940, software power down state is 1 (SPD mode)
>
> If (phydev->suspended && Normal mode)
> Restore PHY specific MMD registers.
Please ignore the above, as I am not an expert in PHY sub system.
Cheers,
Biju
^ permalink raw reply
* Re: [PATCH net-next] net: always inline some skb helpers
From: Simon Horman @ 2026-04-03 16:31 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S. Miller, Jakub Kicinski, Paolo Abeni, Kuniyuki Iwashima,
netdev, eric.dumazet
In-Reply-To: <20260402152654.1720627-1-edumazet@google.com>
On Thu, Apr 02, 2026 at 03:26:54PM +0000, Eric Dumazet wrote:
> Some performance critical helpers from include/linux/skbuff.h
> are not inlined by clang.
>
> Use __always_inline hint for:
>
> - __skb_fill_netmem_desc()
> - __skb_fill_page_desc()
> - skb_fill_netmem_desc()
> - skb_fill_page_desc()
> - __skb_pull()
> - pskb_may_pull_reason()
> - pskb_may_pull()
> - pskb_pull()
> - pskb_trim()
> - skb_orphan()
> - skb_postpull_rcsum()
> - skb_header_pointer()
> - skb_clear_delivery_time()
> - skb_tstamp_cond()
> - skb_warn_if_lro()
>
> This increases performance and saves ~1200 bytes of text.
>
> $ scripts/bloat-o-meter -t vmlinux.old vmlinux.new
> add/remove: 4/24 grow/shrink: 66/12 up/down: 4104/-5306 (-1202)
...
> Total: Before=29652698, After=29651496, chg -0.00%
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Simon Horman <horms@kernel.org>
...
^ permalink raw reply
* [PATCH 0/6] IPA v5.2 support for Milos and Fairphone (Gen. 6)
From: Luca Weiss @ 2026-04-03 16:43 UTC (permalink / raw)
To: Alex Elder, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Alexander Koskovich
Cc: ~postmarketos/upstreaming, phone-devel, netdev, linux-kernel,
linux-arm-msm, devicetree, Luca Weiss
First, two fixes that unbreak IPA v5.0+, which can be applied
independently.
Then add support for IPA v5.2 which can be found in the Milos SoC. And
finally enable it on Fairphone (Gen. 6) so that mobile data (4G/5G/..)
starts working.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
Alexander Koskovich (2):
net: ipa: fix GENERIC_CMD register field masks for IPA v5.0+
net: ipa: fix event ring index not programmed for IPA v5.0+
Luca Weiss (4):
dt-bindings: net: qcom,ipa: add Milos compatible
net: ipa: add IPA v5.2 configuration data
arm64: dts: qcom: milos: Add IPA node
arm64: dts: qcom: milos-fairphone-fp6: Enable IPA
.../devicetree/bindings/net/qcom,ipa.yaml | 1 +
arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts | 9 +
arch/arm64/boot/dts/qcom/milos.dtsi | 44 ++
drivers/net/ipa/Makefile | 2 +-
drivers/net/ipa/data/ipa_data-v5.2.c | 452 +++++++++++++++++++++
drivers/net/ipa/gsi_reg.c | 1 +
drivers/net/ipa/ipa_data.h | 1 +
drivers/net/ipa/ipa_main.c | 4 +
drivers/net/ipa/ipa_reg.c | 1 +
drivers/net/ipa/ipa_sysfs.c | 2 +
drivers/net/ipa/ipa_version.h | 2 +
drivers/net/ipa/reg/gsi_reg-v5.0.c | 9 +-
12 files changed, 523 insertions(+), 5 deletions(-)
---
base-commit: 83acad05dee54a5cff0c98dd7962e55d4c6b145a
change-id: 20260403-milos-ipa-e5705aa87245
prerequisite-change-id: 20260403-milos-imem-3a034224946a:v1
prerequisite-patch-id: 07ad87fc40adfb8dd146b9c0678d099bfe97f679
prerequisite-patch-id: 0f4436a42df3bccb92f753cecfbf24c81f4677c8
Best regards,
--
Luca Weiss <luca.weiss@fairphone.com>
^ permalink raw reply
* [PATCH 1/6] net: ipa: fix GENERIC_CMD register field masks for IPA v5.0+
From: Luca Weiss @ 2026-04-03 16:43 UTC (permalink / raw)
To: Alex Elder, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Alexander Koskovich
Cc: ~postmarketos/upstreaming, phone-devel, netdev, linux-kernel,
linux-arm-msm, devicetree, Luca Weiss
In-Reply-To: <20260403-milos-ipa-v1-0-01e9e4e03d3e@fairphone.com>
From: Alexander Koskovich <akoskovich@pm.me>
Fix the field masks to match the hardware layout documented in
downstream GSI (GSI_V3_0_EE_n_GSI_EE_GENERIC_CMD_*).
Notably this fixes a WARN I was seeing when I tried to send "stop"
to the MPSS remoteproc while IPA was up.
Fixes: faf0678ec8a0 ("net: ipa: add IPA v5.0 GSI register definitions")
Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
drivers/net/ipa/reg/gsi_reg-v5.0.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ipa/reg/gsi_reg-v5.0.c b/drivers/net/ipa/reg/gsi_reg-v5.0.c
index 36d1e65df71b..3334d8e20ad2 100644
--- a/drivers/net/ipa/reg/gsi_reg-v5.0.c
+++ b/drivers/net/ipa/reg/gsi_reg-v5.0.c
@@ -156,9 +156,10 @@ REG_FIELDS(EV_CH_CMD, ev_ch_cmd, 0x00025010 + 0x12000 * GSI_EE_AP);
static const u32 reg_generic_cmd_fmask[] = {
[GENERIC_OPCODE] = GENMASK(4, 0),
- [GENERIC_CHID] = GENMASK(9, 5),
- [GENERIC_EE] = GENMASK(13, 10),
- /* Bits 14-31 reserved */
+ [GENERIC_CHID] = GENMASK(12, 5),
+ [GENERIC_EE] = GENMASK(16, 13),
+ /* Bits 17-23 reserved */
+ [GENERIC_PARAMS] = GENMASK(31, 24),
};
REG_FIELDS(GENERIC_CMD, generic_cmd, 0x00025018 + 0x12000 * GSI_EE_AP);
--
2.53.0
^ permalink raw reply related
* [PATCH 2/6] net: ipa: fix event ring index not programmed for IPA v5.0+
From: Luca Weiss @ 2026-04-03 16:43 UTC (permalink / raw)
To: Alex Elder, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Alexander Koskovich
Cc: ~postmarketos/upstreaming, phone-devel, netdev, linux-kernel,
linux-arm-msm, devicetree, Luca Weiss
In-Reply-To: <20260403-milos-ipa-v1-0-01e9e4e03d3e@fairphone.com>
From: Alexander Koskovich <akoskovich@pm.me>
For IPA v5.0+, the event ring index field moved from CH_C_CNTXT_0 to
CH_C_CNTXT_1. The v5.0 register definition intended to define this
field in the CH_C_CNTXT_1 fmask array but used the old identifier of
ERINDEX instead of CH_ERINDEX.
Without a valid event ring, GSI channels could never signal transfer
completions. This caused gsi_channel_trans_quiesce() to block
forever in wait_for_completion().
At least for IPA v5.2 this resolves an issue seen where runtime
suspend, system suspend, and remoteproc stop all hanged forever. It
also meant the IPA data path was completely non functional.
Fixes: faf0678ec8a0 ("net: ipa: add IPA v5.0 GSI register definitions")
Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
drivers/net/ipa/reg/gsi_reg-v5.0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ipa/reg/gsi_reg-v5.0.c b/drivers/net/ipa/reg/gsi_reg-v5.0.c
index 3334d8e20ad2..6c4a7fbe4de9 100644
--- a/drivers/net/ipa/reg/gsi_reg-v5.0.c
+++ b/drivers/net/ipa/reg/gsi_reg-v5.0.c
@@ -30,7 +30,7 @@ REG_STRIDE_FIELDS(CH_C_CNTXT_0, ch_c_cntxt_0,
static const u32 reg_ch_c_cntxt_1_fmask[] = {
[CH_R_LENGTH] = GENMASK(23, 0),
- [ERINDEX] = GENMASK(31, 24),
+ [CH_ERINDEX] = GENMASK(31, 24),
};
REG_STRIDE_FIELDS(CH_C_CNTXT_1, ch_c_cntxt_1,
--
2.53.0
^ permalink raw reply related
* [PATCH 3/6] dt-bindings: net: qcom,ipa: add Milos compatible
From: Luca Weiss @ 2026-04-03 16:43 UTC (permalink / raw)
To: Alex Elder, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Alexander Koskovich
Cc: ~postmarketos/upstreaming, phone-devel, netdev, linux-kernel,
linux-arm-msm, devicetree, Luca Weiss
In-Reply-To: <20260403-milos-ipa-v1-0-01e9e4e03d3e@fairphone.com>
Add support for the Milos SoC, which uses IPA v5.2.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
Documentation/devicetree/bindings/net/qcom,ipa.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml b/Documentation/devicetree/bindings/net/qcom,ipa.yaml
index e4bb627e1757..fdeaa81b9645 100644
--- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml
+++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml
@@ -44,6 +44,7 @@ properties:
compatible:
oneOf:
- enum:
+ - qcom,milos-ipa
- qcom,msm8998-ipa
- qcom,sc7180-ipa
- qcom,sc7280-ipa
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox