From: netdev-bot+sashiko@kernel.org
To: manivannan.sadhasivam@oss.qualcomm.com
Cc: mani@kernel.org, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, horms@kernel.org,
jjohnson@kernel.org, linux-arm-msm@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org, ath11k@lists.infradead.org,
ath12k@lists.infradead.org, andersson@kernel.org,
christopher.lew@oss.qualcomm.com, deepak.singh@oss.qualcomm.com,
raj.bhagat@oss.qualcomm.com, juha-matti.tilli@iki.fi,
jeff.hugo@oss.qualcomm.com,
vasanthakumar.thiagarajan@oss.qualcomm.com
Subject: Re: [PATCH v3 4/4] wifi: ath12k: Connect to the QMI server belonging to the device owned by this driver
Date: Fri, 25 Sep 2026 07:43:07 +0000 [thread overview]
Message-ID: <179032218792.2160803.6446248222489442159@kernel.org> (raw)
In-Reply-To: <20260922-qrtr-multi-ep-v3-4-c00831e88957@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider.
Critical: 0 · High: 1 · Medium: 0 · Low: 0
If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).
- [High] Asymmetric node-id filtering in ath12k QMI:
ath12k_qmi_ops_new_server()…
--
wifi: ath12k: Connect to the QMI server belonging to the device owned by this driver
This patch adds a get_qrtr_node_id() HIF callback that returns the QRTR node
id derived from the MHI controller index, and uses it in the QMI new_server
callback to skip WLFW services that live on a different node. A node id of
zero keeps the previous unfiltered behaviour.
> diff --git a/drivers/net/wireless/ath/ath12k/qmi.c b/drivers/net/wireless/ath/ath12k/qmi.c
> index 280e50a1f31d8..e1e75cc9d1441 100644
> --- a/drivers/net/wireless/ath/ath12k/qmi.c
> +++ b/drivers/net/wireless/ath/ath12k/qmi.c
[ ... ]
> @@ -3940,8 +3941,18 @@ static int ath12k_qmi_ops_new_server(struct qmi_handle *qmi_hdl,
> struct ath12k_qmi *qmi = container_of(qmi_hdl, struct ath12k_qmi, handle);
> struct ath12k_base *ab = qmi->ab;
> struct sockaddr_qrtr *sq = &qmi->sq;
> + unsigned int node_id;
> int ret;
>
> + /* Identical devices advertise the same QMI services, so connect only to
> + * the QMI server on this device's node. A node id of 0 means the
> + * transport has not assigned a unique node id, so accept the server
> + * unfiltered.
> + */
> + node_id = ath12k_hif_get_qrtr_node_id(ab);
> + if (node_id && service->node != node_id)
> + return 0;
> +
[Severity: High]
Should this return a negative errno instead of 0 for the foreign node?
In drivers/soc/qcom/qmi_interface.c, qmi_recv_new_server() only discards the
service record when the callback returns a negative value:
ret = ops->new_server(qmi, svc);
if (ret < 0)
kfree(svc);
else
list_add(&svc->list_node, &qmi->lookup_results);
With the return 0 above, the other device's WLFW service stays in this
handle's lookup_results even though this device never connected to it.
The matching teardown path in the same qmi_ops table has no node id check:
drivers/net/wireless/ath/ath12k/qmi.c:ath12k_qmi_ops_del_server() {
struct ath12k_qmi *qmi = container_of(qmi_hdl, struct ath12k_qmi, handle);
struct ath12k_base *ab = qmi->ab;
ath12k_dbg(ab, ATH12K_DBG_QMI, "qmi wifi fw del server\n");
ath12k_qmi_driver_event_post(qmi, ATH12K_QMI_EVENT_SERVER_EXIT, NULL);
}
and qmi_recv_del_server() invokes it for every retained entry whose node
matches, with qmi_recv_bye() passing port == -1 to match all ports on the
dying node:
drivers/soc/qcom/qmi_interface.c:qmi_recv_del_server() {
list_for_each_entry_safe(svc, tmp, &qmi->lookup_results, list_node) {
if (node != -1 && svc->node != node)
continue;
if (port != -1 && svc->port != port)
continue;
if (ops->del_server)
ops->del_server(qmi, svc);
...
}
net/qrtr/ns.c:server_del() notifies every lookup matching service/instance
regardless of node, so device A's handle does receive DEL_SERVER or BYE for
device B's node when device B's firmware crashes or that card is unbound or
hot-removed.
Can that spuriously fault the healthy device? The event worker reacts to
SERVER_EXIT unconditionally:
drivers/net/wireless/ath/ath12k/qmi.c:ath12k_qmi_driver_event_work() {
...
case ATH12K_QMI_EVENT_SERVER_EXIT:
set_bit(ATH12K_FLAG_CRASH_FLUSH, &ab->dev_flags);
...
}
ATH12K_FLAG_CRASH_FLUSH makes CE sends, WMI sends, data TX
(ath12k_wifi7_dp_tx()) and mgmt TX return -ESHUTDOWN, and it makes
ath12k_core_stop() skip ath12k_dp_reoq_lut_addr_reset() and
ath12k_qmi_firmware_stop() on a device whose firmware is still running:
drivers/net/wireless/ath/ath12k/core.c:ath12k_core_stop() {
if (!test_bit(ATH12K_FLAG_CRASH_FLUSH, &ab->dev_flags)) {
ath12k_dp_reoq_lut_addr_reset(ath12k_ab_to_dp(ab));
ath12k_qmi_firmware_stop(ab);
}
...
}
The flag is only cleared on a later FW_READY event or on core reconfigure,
so the untouched device can stay in this state indefinitely.
Would returning a negative errno here (so the foreign service is never
tracked), and/or adding the same service->node check to
ath12k_qmi_ops_del_server(), cover the teardown direction as well?
There is a second effect from the retained entries: each filtered
NEW_SERVER adds another node of the foreign device into lookup_results,
so a foreign device in a firmware restart loop accumulates duplicate
entries that each later produce their own SERVER_EXIT post.
--
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260922-qrtr-multi-ep-v3-0-c00831e88957%40oss.qualcomm.com
prev parent reply other threads:[~2026-09-25 7:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 13:41 [PATCH v3 0/4] net: qrtr: Add support for using identical MHI endpoint devices Manivannan Sadhasivam via B4 Relay
2026-09-22 13:41 ` [PATCH v3 1/4] net: qrtr: Allow the host QRTR to assign a unique node id Manivannan Sadhasivam via B4 Relay
2026-09-25 7:43 ` netdev-bot+sashiko
2026-09-22 13:41 ` [PATCH v3 2/4] net: qrtr: Assign unique node id for MHI endpoints Manivannan Sadhasivam via B4 Relay
2026-09-25 7:43 ` netdev-bot+sashiko
2026-09-22 13:41 ` [PATCH v3 3/4] wifi: ath11k: Connect to the QMI server belonging to the device owned by this driver Manivannan Sadhasivam via B4 Relay
2026-09-25 7:43 ` netdev-bot+sashiko
2026-09-22 13:41 ` [PATCH v3 4/4] wifi: ath12k: " Manivannan Sadhasivam via B4 Relay
2026-09-22 15:52 ` Raj Kumar Bhagat
2026-09-23 6:42 ` Juha-Matti Tilli
2026-09-25 7:43 ` netdev-bot+sashiko [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=179032218792.2160803.6446248222489442159@kernel.org \
--to=netdev-bot+sashiko@kernel.org \
--cc=andersson@kernel.org \
--cc=ath11k@lists.infradead.org \
--cc=ath12k@lists.infradead.org \
--cc=christopher.lew@oss.qualcomm.com \
--cc=davem@davemloft.net \
--cc=deepak.singh@oss.qualcomm.com \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jeff.hugo@oss.qualcomm.com \
--cc=jjohnson@kernel.org \
--cc=juha-matti.tilli@iki.fi \
--cc=kuba@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=mani@kernel.org \
--cc=manivannan.sadhasivam@oss.qualcomm.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=raj.bhagat@oss.qualcomm.com \
--cc=vasanthakumar.thiagarajan@oss.qualcomm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®