* [PATCH v1 2/8] net: ipa: Use the unified QMI service ID instead of defining it locally
From: Daniel Lezcano @ 2026-03-09 23:03 UTC (permalink / raw)
To: konradybcio, andersson
Cc: linux-kernel, Alex Elder, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Jeff Johnson,
Mathieu Poirier, Srinivas Kandagatla, Jaroslav Kysela,
Takashi Iwai, Kees Cook, Greg Kroah-Hartman, Arnd Bergmann,
Mark Brown, Wesley Cheng, netdev, linux-wireless, ath10k, ath11k,
ath12k, linux-arm-msm, linux-remoteproc, linux-sound
In-Reply-To: <20260309230346.3584252-1-daniel.lezcano@oss.qualcomm.com>
Instead of defining a local macro with a custom name for the QMI
service identifier, use the one provided in qmi.h and remove the
locally defined macro.
Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
---
drivers/net/ipa/ipa_qmi.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ipa/ipa_qmi.c b/drivers/net/ipa/ipa_qmi.c
index d771f3a71f94..37936ad132a2 100644
--- a/drivers/net/ipa/ipa_qmi.c
+++ b/drivers/net/ipa/ipa_qmi.c
@@ -66,11 +66,9 @@
* determination of when things are "ready"
*/
-#define IPA_HOST_SERVICE_SVC_ID 0x31
#define IPA_HOST_SVC_VERS 1
#define IPA_HOST_SERVICE_INS_ID 1
-#define IPA_MODEM_SERVICE_SVC_ID 0x31
#define IPA_MODEM_SERVICE_INS_ID 2
#define IPA_MODEM_SVC_VERS 1
@@ -484,7 +482,7 @@ int ipa_qmi_setup(struct ipa *ipa)
if (ret)
return ret;
- ret = qmi_add_server(&ipa_qmi->server_handle, IPA_HOST_SERVICE_SVC_ID,
+ ret = qmi_add_server(&ipa_qmi->server_handle, QMI_SERVICE_ID_IPA,
IPA_HOST_SVC_VERS, IPA_HOST_SERVICE_INS_ID);
if (ret)
goto err_server_handle_release;
@@ -501,7 +499,7 @@ int ipa_qmi_setup(struct ipa *ipa)
/* We need this ready before the service lookup is added */
INIT_WORK(&ipa_qmi->init_driver_work, ipa_client_init_driver_work);
- ret = qmi_add_lookup(&ipa_qmi->client_handle, IPA_MODEM_SERVICE_SVC_ID,
+ ret = qmi_add_lookup(&ipa_qmi->client_handle, QMI_SERVICE_ID_IPA,
IPA_MODEM_SVC_VERS, IPA_MODEM_SERVICE_INS_ID);
if (ret)
goto err_client_handle_release;
--
2.43.0
^ permalink raw reply related
* [PATCH v1 3/8] net: drivers: wireless: ath: Use the unified QMI service ID instead of defining it locally
From: Daniel Lezcano @ 2026-03-09 23:03 UTC (permalink / raw)
To: konradybcio, andersson
Cc: linux-kernel, Alex Elder, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Jeff Johnson,
Mathieu Poirier, Srinivas Kandagatla, Jaroslav Kysela,
Takashi Iwai, Kees Cook, Greg Kroah-Hartman, Arnd Bergmann,
Mark Brown, Wesley Cheng, netdev, linux-wireless, ath10k, ath11k,
ath12k, linux-arm-msm, linux-remoteproc, linux-sound
In-Reply-To: <20260309230346.3584252-1-daniel.lezcano@oss.qualcomm.com>
Instead of defining a local macro with a custom name for the QMI
service identifier, use the one provided in qmi.h and remove the
locally defined macro.
Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/qmi.c | 2 +-
drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.h | 1 -
drivers/net/wireless/ath/ath11k/qmi.c | 2 +-
drivers/net/wireless/ath/ath11k/qmi.h | 1 -
drivers/net/wireless/ath/ath12k/qmi.c | 2 +-
drivers/net/wireless/ath/ath12k/qmi.h | 1 -
6 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/qmi.c b/drivers/net/wireless/ath/ath10k/qmi.c
index eebd78e7ff6b..4fdd0af415d5 100644
--- a/drivers/net/wireless/ath/ath10k/qmi.c
+++ b/drivers/net/wireless/ath/ath10k/qmi.c
@@ -1105,7 +1105,7 @@ int ath10k_qmi_init(struct ath10k *ar, u32 msa_size)
spin_lock_init(&qmi->event_lock);
INIT_WORK(&qmi->event_work, ath10k_qmi_driver_event_work);
- ret = qmi_add_lookup(&qmi->qmi_hdl, WLFW_SERVICE_ID_V01,
+ ret = qmi_add_lookup(&qmi->qmi_hdl, QMI_SERVICE_ID_WLFW,
WLFW_SERVICE_VERS_V01, 0);
if (ret)
goto err_qmi_lookup;
diff --git a/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.h b/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.h
index 9f311f3bc9e7..88d58f78989d 100644
--- a/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.h
+++ b/drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.h
@@ -7,7 +7,6 @@
#ifndef WCN3990_QMI_SVC_V01_H
#define WCN3990_QMI_SVC_V01_H
-#define WLFW_SERVICE_ID_V01 0x45
#define WLFW_SERVICE_VERS_V01 0x01
#define QMI_WLFW_BDF_DOWNLOAD_REQ_V01 0x0025
diff --git a/drivers/net/wireless/ath/ath11k/qmi.c b/drivers/net/wireless/ath/ath11k/qmi.c
index feebbc30f3df..1397756d6251 100644
--- a/drivers/net/wireless/ath/ath11k/qmi.c
+++ b/drivers/net/wireless/ath/ath11k/qmi.c
@@ -3337,7 +3337,7 @@ int ath11k_qmi_init_service(struct ath11k_base *ab)
spin_lock_init(&ab->qmi.event_lock);
INIT_WORK(&ab->qmi.event_work, ath11k_qmi_driver_event_work);
- ret = qmi_add_lookup(&ab->qmi.handle, ATH11K_QMI_WLFW_SERVICE_ID_V01,
+ ret = qmi_add_lookup(&ab->qmi.handle, QMI_SERVICE_ID_WLFW,
ATH11K_QMI_WLFW_SERVICE_VERS_V01,
ab->qmi.service_ins_id);
if (ret < 0) {
diff --git a/drivers/net/wireless/ath/ath11k/qmi.h b/drivers/net/wireless/ath/ath11k/qmi.h
index 7968ab122b65..eae416db8b52 100644
--- a/drivers/net/wireless/ath/ath11k/qmi.h
+++ b/drivers/net/wireless/ath/ath11k/qmi.h
@@ -15,7 +15,6 @@
#define ATH11K_QMI_MAX_BDF_FILE_NAME_SIZE 64
#define ATH11K_QMI_CALDB_ADDRESS 0x4BA00000
#define ATH11K_QMI_WLANFW_MAX_BUILD_ID_LEN_V01 128
-#define ATH11K_QMI_WLFW_SERVICE_ID_V01 0x45
#define ATH11K_QMI_WLFW_SERVICE_VERS_V01 0x01
#define ATH11K_QMI_WLFW_SERVICE_INS_ID_V01 0x02
#define ATH11K_QMI_WLFW_SERVICE_INS_ID_V01_QCA6390 0x01
diff --git a/drivers/net/wireless/ath/ath12k/qmi.c b/drivers/net/wireless/ath/ath12k/qmi.c
index c11b84b56f8f..f31cba7af722 100644
--- a/drivers/net/wireless/ath/ath12k/qmi.c
+++ b/drivers/net/wireless/ath/ath12k/qmi.c
@@ -4061,7 +4061,7 @@ int ath12k_qmi_init_service(struct ath12k_base *ab)
spin_lock_init(&ab->qmi.event_lock);
INIT_WORK(&ab->qmi.event_work, ath12k_qmi_driver_event_work);
- ret = qmi_add_lookup(&ab->qmi.handle, ATH12K_QMI_WLFW_SERVICE_ID_V01,
+ ret = qmi_add_lookup(&ab->qmi.handle, QMI_SERVICE_ID_WLFW,
ATH12K_QMI_WLFW_SERVICE_VERS_V01,
ab->qmi.service_ins_id);
if (ret < 0) {
diff --git a/drivers/net/wireless/ath/ath12k/qmi.h b/drivers/net/wireless/ath/ath12k/qmi.h
index b5a4a01391cb..2a63e214eb42 100644
--- a/drivers/net/wireless/ath/ath12k/qmi.h
+++ b/drivers/net/wireless/ath/ath12k/qmi.h
@@ -15,7 +15,6 @@
#define ATH12K_QMI_MAX_BDF_FILE_NAME_SIZE 64
#define ATH12K_QMI_CALDB_ADDRESS 0x4BA00000
#define ATH12K_QMI_WLANFW_MAX_BUILD_ID_LEN_V01 128
-#define ATH12K_QMI_WLFW_SERVICE_ID_V01 0x45
#define ATH12K_QMI_WLFW_SERVICE_VERS_V01 0x01
#define ATH12K_QMI_WLFW_SERVICE_INS_ID_V01 0x02
#define ATH12K_QMI_WLFW_SERVICE_INS_ID_V01_WCN7850 0x1
--
2.43.0
^ permalink raw reply related
* [PATCH v1 4/8] remoteproc: qcom: Use the unified QMI service ID instead of defining it locally
From: Daniel Lezcano @ 2026-03-09 23:03 UTC (permalink / raw)
To: konradybcio, andersson
Cc: linux-kernel, Alex Elder, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Jeff Johnson,
Mathieu Poirier, Srinivas Kandagatla, Jaroslav Kysela,
Takashi Iwai, Kees Cook, Greg Kroah-Hartman, Arnd Bergmann,
Mark Brown, Wesley Cheng, netdev, linux-wireless, ath10k, ath11k,
ath12k, linux-arm-msm, linux-remoteproc, linux-sound
In-Reply-To: <20260309230346.3584252-1-daniel.lezcano@oss.qualcomm.com>
Instead of defining a local macro with a custom name for the QMI
service identifier, use the one provided in qmi.h and remove the
locally defined macro.
Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
---
drivers/remoteproc/qcom_sysmon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/remoteproc/qcom_sysmon.c b/drivers/remoteproc/qcom_sysmon.c
index cf10e8ecfb8f..5bd4147f1f37 100644
--- a/drivers/remoteproc/qcom_sysmon.c
+++ b/drivers/remoteproc/qcom_sysmon.c
@@ -677,7 +677,7 @@ struct qcom_sysmon *qcom_add_sysmon_subdev(struct rproc *rproc,
return ERR_PTR(ret);
}
- qmi_add_lookup(&sysmon->qmi, 43, 0, 0);
+ qmi_add_lookup(&sysmon->qmi, QMI_SERVICE_ID_SSCTL, 0, 0);
sysmon->subdev.prepare = sysmon_prepare;
sysmon->subdev.start = sysmon_start;
--
2.43.0
^ permalink raw reply related
* [PATCH v1 5/8] slimbus: qcom-ngd-ctrl: Use the unified QMI service ID instead of defining it locally
From: Daniel Lezcano @ 2026-03-09 23:03 UTC (permalink / raw)
To: konradybcio, andersson
Cc: linux-kernel, Alex Elder, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Jeff Johnson,
Mathieu Poirier, Srinivas Kandagatla, Jaroslav Kysela,
Takashi Iwai, Kees Cook, Greg Kroah-Hartman, Arnd Bergmann,
Mark Brown, Wesley Cheng, netdev, linux-wireless, ath10k, ath11k,
ath12k, linux-arm-msm, linux-remoteproc, linux-sound
In-Reply-To: <20260309230346.3584252-1-daniel.lezcano@oss.qualcomm.com>
Instead of defining a local macro with a custom name for the QMI
service identifier, use the one provided in qmi.h and remove the
locally defined macro.
Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
---
drivers/slimbus/qcom-ngd-ctrl.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/slimbus/qcom-ngd-ctrl.c b/drivers/slimbus/qcom-ngd-ctrl.c
index 9aa7218b4e8d..0b88b8577bdb 100644
--- a/drivers/slimbus/qcom-ngd-ctrl.c
+++ b/drivers/slimbus/qcom-ngd-ctrl.c
@@ -48,7 +48,6 @@
NGD_INT_RX_MSG_RCVD)
/* Slimbus QMI service */
-#define SLIMBUS_QMI_SVC_ID 0x0301
#define SLIMBUS_QMI_SVC_V1 1
#define SLIMBUS_QMI_INS_ID 0
#define SLIMBUS_QMI_SELECT_INSTANCE_REQ_V01 0x0020
@@ -1408,8 +1407,8 @@ static int qcom_slim_ngd_qmi_svc_event_init(struct qcom_slim_ngd_ctrl *ctrl)
return ret;
}
- ret = qmi_add_lookup(&qmi->svc_event_hdl, SLIMBUS_QMI_SVC_ID,
- SLIMBUS_QMI_SVC_V1, SLIMBUS_QMI_INS_ID);
+ ret = qmi_add_lookup(&qmi->svc_event_hdl, QMI_SERVICE_ID_SLIMBUS,
+ SLIMBUS_QMI_SVC_V1, SLIMBUS_QMI_INS_ID);
if (ret < 0) {
dev_err(ctrl->dev, "qmi_add_lookup failed: %d\n", ret);
qmi_handle_release(&qmi->svc_event_hdl);
--
2.43.0
^ permalink raw reply related
* [PATCH v1 6/8] soc: qcom: pdr: Use the unified QMI service ID instead of defining it locally
From: Daniel Lezcano @ 2026-03-09 23:03 UTC (permalink / raw)
To: konradybcio, andersson
Cc: linux-kernel, Alex Elder, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Jeff Johnson,
Mathieu Poirier, Srinivas Kandagatla, Jaroslav Kysela,
Takashi Iwai, Kees Cook, Greg Kroah-Hartman, Arnd Bergmann,
Mark Brown, Wesley Cheng, netdev, linux-wireless, ath10k, ath11k,
ath12k, linux-arm-msm, linux-remoteproc, linux-sound
In-Reply-To: <20260309230346.3584252-1-daniel.lezcano@oss.qualcomm.com>
Instead of defining a local macro with a custom name for the QMI
service identifier, use the one provided in qmi.h and remove the
locally defined macro.
Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
---
drivers/soc/qcom/pdr_interface.c | 4 ++--
drivers/soc/qcom/pdr_internal.h | 3 ---
drivers/soc/qcom/qcom_pd_mapper.c | 2 +-
3 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/soc/qcom/pdr_interface.c b/drivers/soc/qcom/pdr_interface.c
index 72259f489075..6d879e1540b0 100644
--- a/drivers/soc/qcom/pdr_interface.c
+++ b/drivers/soc/qcom/pdr_interface.c
@@ -523,7 +523,7 @@ struct pdr_service *pdr_add_lookup(struct pdr_handle *pdr,
if (!pds)
return ERR_PTR(-ENOMEM);
- pds->service = SERVREG_NOTIFIER_SERVICE;
+ pds->service = QMI_SERVICE_ID_SERVREG_NOTIF;
strscpy(pds->service_name, service_name, sizeof(pds->service_name));
strscpy(pds->service_path, service_path, sizeof(pds->service_path));
pds->need_locator_lookup = true;
@@ -678,7 +678,7 @@ struct pdr_handle *pdr_handle_alloc(void (*status)(int state,
if (ret < 0)
goto destroy_indack;
- ret = qmi_add_lookup(&pdr->locator_hdl, SERVREG_LOCATOR_SERVICE, 1, 1);
+ ret = qmi_add_lookup(&pdr->locator_hdl, QMI_SERVICE_ID_SERVREG_LOC, 1, 1);
if (ret < 0)
goto release_qmi_handle;
diff --git a/drivers/soc/qcom/pdr_internal.h b/drivers/soc/qcom/pdr_internal.h
index 039508c1bbf7..6cd8cbe26822 100644
--- a/drivers/soc/qcom/pdr_internal.h
+++ b/drivers/soc/qcom/pdr_internal.h
@@ -4,9 +4,6 @@
#include <linux/soc/qcom/pdr.h>
-#define SERVREG_LOCATOR_SERVICE 0x40
-#define SERVREG_NOTIFIER_SERVICE 0x42
-
#define SERVREG_REGISTER_LISTENER_REQ 0x20
#define SERVREG_GET_DOMAIN_LIST_REQ 0x21
#define SERVREG_STATE_UPDATED_IND_ID 0x22
diff --git a/drivers/soc/qcom/qcom_pd_mapper.c b/drivers/soc/qcom/qcom_pd_mapper.c
index dc10bc859ff4..bb60b5c40554 100644
--- a/drivers/soc/qcom/qcom_pd_mapper.c
+++ b/drivers/soc/qcom/qcom_pd_mapper.c
@@ -656,7 +656,7 @@ static struct qcom_pdm_data *qcom_pdm_start(void)
goto err_stop;
}
- ret = qmi_add_server(&data->handle, SERVREG_LOCATOR_SERVICE,
+ ret = qmi_add_server(&data->handle, QMI_SERVICE_ID_SERVREG_LOC,
SERVREG_QMI_VERSION, SERVREG_QMI_INSTANCE);
if (ret) {
pr_err("PDM: error adding server %d\n", ret);
--
2.43.0
^ permalink raw reply related
* [PATCH v1 7/8] ALSA: usb-audio: qcom: Use the unified QMI service ID instead of defining it locally
From: Daniel Lezcano @ 2026-03-09 23:03 UTC (permalink / raw)
To: konradybcio, andersson
Cc: linux-kernel, Alex Elder, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Jeff Johnson,
Mathieu Poirier, Srinivas Kandagatla, Jaroslav Kysela,
Takashi Iwai, Kees Cook, Greg Kroah-Hartman, Arnd Bergmann,
Mark Brown, Wesley Cheng, netdev, linux-wireless, ath10k, ath11k,
ath12k, linux-arm-msm, linux-remoteproc, linux-sound,
Erick Karanja
In-Reply-To: <20260309230346.3584252-1-daniel.lezcano@oss.qualcomm.com>
Instead of defining a local macro with a custom name for the QMI
service identifier, use the one provided in qmi.h and remove the
locally defined macro.
Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
---
sound/usb/qcom/qc_audio_offload.c | 2 +-
sound/usb/qcom/usb_audio_qmi_v01.h | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/sound/usb/qcom/qc_audio_offload.c b/sound/usb/qcom/qc_audio_offload.c
index 510b68cced33..bc4e1bdacaa8 100644
--- a/sound/usb/qcom/qc_audio_offload.c
+++ b/sound/usb/qcom/qc_audio_offload.c
@@ -1927,7 +1927,7 @@ static int qc_usb_audio_probe(struct auxiliary_device *auxdev,
QMI_UAUDIO_STREAM_REQ_MSG_V01_MAX_MSG_LEN,
&uaudio_svc_ops_options,
&uaudio_stream_req_handlers);
- ret = qmi_add_server(svc->uaudio_svc_hdl, UAUDIO_STREAM_SERVICE_ID_V01,
+ ret = qmi_add_server(svc->uaudio_svc_hdl, QMI_SERVICE_ID_USB_AUDIO_STREAM,
UAUDIO_STREAM_SERVICE_VERS_V01, 0);
uaudio_svc = svc;
diff --git a/sound/usb/qcom/usb_audio_qmi_v01.h b/sound/usb/qcom/usb_audio_qmi_v01.h
index a1298d75d9f8..c7eee03225ec 100644
--- a/sound/usb/qcom/usb_audio_qmi_v01.h
+++ b/sound/usb/qcom/usb_audio_qmi_v01.h
@@ -6,7 +6,6 @@
#ifndef USB_QMI_V01_H
#define USB_QMI_V01_H
-#define UAUDIO_STREAM_SERVICE_ID_V01 0x41D
#define UAUDIO_STREAM_SERVICE_VERS_V01 0x01
#define QMI_UAUDIO_STREAM_RESP_V01 0x0001
--
2.43.0
^ permalink raw reply related
* [PATCH v1 8/8] samples: qmi: Use the unified QMI service ID instead of defining it locally
From: Daniel Lezcano @ 2026-03-09 23:03 UTC (permalink / raw)
To: konradybcio, andersson
Cc: linux-kernel, Alex Elder, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Jeff Johnson,
Mathieu Poirier, Srinivas Kandagatla, Jaroslav Kysela,
Takashi Iwai, Kees Cook, Greg Kroah-Hartman, Arnd Bergmann,
Mark Brown, Wesley Cheng, netdev, linux-wireless, ath10k, ath11k,
ath12k, linux-arm-msm, linux-remoteproc, linux-sound
In-Reply-To: <20260309230346.3584252-1-daniel.lezcano@oss.qualcomm.com>
Instead of defining a local macro with a custom name for the QMI
service identifier, use the one provided in qmi.h and remove the
locally defined macro.
Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
---
samples/qmi/qmi_sample_client.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/samples/qmi/qmi_sample_client.c b/samples/qmi/qmi_sample_client.c
index d1814582319b..247ec5e54c4f 100644
--- a/samples/qmi/qmi_sample_client.c
+++ b/samples/qmi/qmi_sample_client.c
@@ -592,7 +592,7 @@ static int qmi_sample_init(void)
if (ret < 0)
goto err_unregister_driver;
- qmi_add_lookup(&lookup_client, 15, 0, 0);
+ qmi_add_lookup(&lookup_client, QMI_SERVICE_ID_TEST, 0, 0);
return 0;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v1 0/8] Group QMI service IDs into the QMI header
From: Jeff Johnson @ 2026-03-09 23:50 UTC (permalink / raw)
To: Daniel Lezcano, konradybcio, andersson
Cc: linux-kernel, Alex Elder, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Jeff Johnson,
Mathieu Poirier, Srinivas Kandagatla, Jaroslav Kysela,
Takashi Iwai, Kees Cook, Greg Kroah-Hartman, Arnd Bergmann,
Mark Brown, Wesley Cheng, netdev, linux-wireless, ath10k, ath11k,
ath12k, linux-arm-msm, linux-remoteproc, linux-sound
In-Reply-To: <20260309230346.3584252-1-daniel.lezcano@oss.qualcomm.com>
On 3/9/2026 4:03 PM, Daniel Lezcano wrote:
> The different subsystems implementing the QMI service protocol are
> using their own definition of the service id. It is not a problem but
> it results on having those duplicated with different names but the
> same value and without consistency in their name.
>
> It makes more sense to unify their names and move the definitions in
> the QMI header file providing a consistent way to represent the
> supported protocols. Consequently the different drivers will use them
> instead of their own definition of the service id.
>
> Cc: Alex Elder <elder@kernel.org>
> Cc: Andrew Lunn <andrew+netdev@lunn.ch>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: Paolo Abeni <pabeni@redhat.com>
> Cc: Jeff Johnson <jjohnson@kernel.org>
> Cc: Bjorn Andersson <andersson@kernel.org>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Cc: Srinivas Kandagatla <srini@kernel.org>
> Cc: Konrad Dybcio <konradybcio@kernel.org>
> Cc: Jaroslav Kysela <perex@perex.cz>
> Cc: Takashi Iwai <tiwai@suse.com>
> Cc: Kees Cook <kees@kernel.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Wesley Cheng <quic_wcheng@quicinc.com>
> Cc: netdev@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-wireless@vger.kernel.org
> Cc: ath10k@lists.infradead.org
> Cc: ath11k@lists.infradead.org
> Cc: ath12k@lists.infradead.org
> Cc: linux-arm-msm@vger.kernel.org
> Cc: linux-remoteproc@vger.kernel.org
> Cc: linux-sound@vger.kernel.org
> ---
> Daniel Lezcano (8):
> soc: qcom: qmi: Enumerate the service IDs of QMI
> net: ipa: Use the unified QMI service ID instead of defining it
> locally
> net: drivers: wireless: ath: Use the unified QMI service ID instead of
> defining it locally
prefix for wireless drivers is simply wifi: <driver>:
so s/net: drivers: wireless:/wifi:/
> remoteproc: qcom: Use the unified QMI service ID instead of defining
> it locally
> slimbus: qcom-ngd-ctrl: Use the unified QMI service ID instead of
> defining it locally
> soc: qcom: pdr: Use the unified QMI service ID instead of defining it
> locally
> ALSA: usb-audio: qcom: Use the unified QMI service ID instead of
> defining it locally
> samples: qmi: Use the unified QMI service ID instead of defining it
> locally
>
> drivers/net/ipa/ipa_qmi.c | 6 ++----
> drivers/net/wireless/ath/ath10k/qmi.c | 2 +-
> drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.h | 1 -
> drivers/net/wireless/ath/ath11k/qmi.c | 2 +-
> drivers/net/wireless/ath/ath11k/qmi.h | 1 -
> drivers/net/wireless/ath/ath12k/qmi.c | 2 +-
> drivers/net/wireless/ath/ath12k/qmi.h | 1 -
> drivers/remoteproc/qcom_sysmon.c | 2 +-
> drivers/slimbus/qcom-ngd-ctrl.c | 5 ++---
> drivers/soc/qcom/pdr_interface.c | 4 ++--
> drivers/soc/qcom/pdr_internal.h | 3 ---
> drivers/soc/qcom/qcom_pd_mapper.c | 2 +-
> include/linux/soc/qcom/qmi.h | 12 ++++++++++++
> samples/qmi/qmi_sample_client.c | 2 +-
> sound/usb/qcom/qc_audio_offload.c | 2 +-
> sound/usb/qcom/usb_audio_qmi_v01.h | 1 -
You are touching a lot of subsystems with a single series.
How do you plan on having these land?
Do you have a maintainer who will take all of these through their tree?
> 16 files changed, 25 insertions(+), 23 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v1 1/8] soc: qcom: qmi: Enumerate the service IDs of QMI
From: Dmitry Baryshkov @ 2026-03-10 0:04 UTC (permalink / raw)
To: Daniel Lezcano
Cc: konradybcio, andersson, linux-kernel, Alex Elder, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jeff Johnson, Mathieu Poirier, Srinivas Kandagatla,
Jaroslav Kysela, Takashi Iwai, Kees Cook, Greg Kroah-Hartman,
Arnd Bergmann, Mark Brown, Wesley Cheng, netdev, linux-wireless,
ath10k, ath11k, ath12k, linux-arm-msm, linux-remoteproc,
linux-sound
In-Reply-To: <20260309230346.3584252-2-daniel.lezcano@oss.qualcomm.com>
On Tue, Mar 10, 2026 at 12:03:30AM +0100, Daniel Lezcano wrote:
> The QMI framework proposes a set of services which are defined by an
> integer identifier. The different QMI client lookup for the services
> via this identifier. Moreover, the function qmi_add_lookup() and
> qmi_add_server() must match the service ID but the code in different
> places set the same value but with a different macro name. These
> macros are spreaded across the different subsystems implementing the
> protocols associated with a service. It would make more sense to
> define them in the QMI header for the sake of consistency and clarity.
>
> This change use an unified naming for the services and enumerate the
Nit: see Documentation/process/submitting-patches.rst, "This patch"
Other than that,
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ones implemented in the Linux kernel. More services can come later and
> put the service ID in this same header.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
> ---
> include/linux/soc/qcom/qmi.h | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v1 2/8] net: ipa: Use the unified QMI service ID instead of defining it locally
From: Dmitry Baryshkov @ 2026-03-10 0:04 UTC (permalink / raw)
To: Daniel Lezcano
Cc: konradybcio, andersson, linux-kernel, Alex Elder, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jeff Johnson, Mathieu Poirier, Srinivas Kandagatla,
Jaroslav Kysela, Takashi Iwai, Kees Cook, Greg Kroah-Hartman,
Arnd Bergmann, Mark Brown, Wesley Cheng, netdev, linux-wireless,
ath10k, ath11k, ath12k, linux-arm-msm, linux-remoteproc,
linux-sound
In-Reply-To: <20260309230346.3584252-3-daniel.lezcano@oss.qualcomm.com>
On Tue, Mar 10, 2026 at 12:03:31AM +0100, Daniel Lezcano wrote:
> Instead of defining a local macro with a custom name for the QMI
> service identifier, use the one provided in qmi.h and remove the
> locally defined macro.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
> ---
> drivers/net/ipa/ipa_qmi.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v1 3/8] net: drivers: wireless: ath: Use the unified QMI service ID instead of defining it locally
From: Dmitry Baryshkov @ 2026-03-10 0:05 UTC (permalink / raw)
To: Daniel Lezcano
Cc: konradybcio, andersson, linux-kernel, Alex Elder, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jeff Johnson, Mathieu Poirier, Srinivas Kandagatla,
Jaroslav Kysela, Takashi Iwai, Kees Cook, Greg Kroah-Hartman,
Arnd Bergmann, Mark Brown, Wesley Cheng, netdev, linux-wireless,
ath10k, ath11k, ath12k, linux-arm-msm, linux-remoteproc,
linux-sound
In-Reply-To: <20260309230346.3584252-4-daniel.lezcano@oss.qualcomm.com>
On Tue, Mar 10, 2026 at 12:03:32AM +0100, Daniel Lezcano wrote:
> Instead of defining a local macro with a custom name for the QMI
> service identifier, use the one provided in qmi.h and remove the
> locally defined macro.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
> ---
> drivers/net/wireless/ath/ath10k/qmi.c | 2 +-
> drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.h | 1 -
> drivers/net/wireless/ath/ath11k/qmi.c | 2 +-
> drivers/net/wireless/ath/ath11k/qmi.h | 1 -
> drivers/net/wireless/ath/ath12k/qmi.c | 2 +-
> drivers/net/wireless/ath/ath12k/qmi.h | 1 -
> 6 files changed, 3 insertions(+), 6 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v1 4/8] remoteproc: qcom: Use the unified QMI service ID instead of defining it locally
From: Dmitry Baryshkov @ 2026-03-10 0:05 UTC (permalink / raw)
To: Daniel Lezcano
Cc: konradybcio, andersson, linux-kernel, Alex Elder, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jeff Johnson, Mathieu Poirier, Srinivas Kandagatla,
Jaroslav Kysela, Takashi Iwai, Kees Cook, Greg Kroah-Hartman,
Arnd Bergmann, Mark Brown, Wesley Cheng, netdev, linux-wireless,
ath10k, ath11k, ath12k, linux-arm-msm, linux-remoteproc,
linux-sound
In-Reply-To: <20260309230346.3584252-5-daniel.lezcano@oss.qualcomm.com>
On Tue, Mar 10, 2026 at 12:03:33AM +0100, Daniel Lezcano wrote:
> Instead of defining a local macro with a custom name for the QMI
> service identifier, use the one provided in qmi.h and remove the
> locally defined macro.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
> ---
> drivers/remoteproc/qcom_sysmon.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v1 5/8] slimbus: qcom-ngd-ctrl: Use the unified QMI service ID instead of defining it locally
From: Dmitry Baryshkov @ 2026-03-10 0:06 UTC (permalink / raw)
To: Daniel Lezcano
Cc: konradybcio, andersson, linux-kernel, Alex Elder, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jeff Johnson, Mathieu Poirier, Srinivas Kandagatla,
Jaroslav Kysela, Takashi Iwai, Kees Cook, Greg Kroah-Hartman,
Arnd Bergmann, Mark Brown, Wesley Cheng, netdev, linux-wireless,
ath10k, ath11k, ath12k, linux-arm-msm, linux-remoteproc,
linux-sound
In-Reply-To: <20260309230346.3584252-6-daniel.lezcano@oss.qualcomm.com>
On Tue, Mar 10, 2026 at 12:03:34AM +0100, Daniel Lezcano wrote:
> Instead of defining a local macro with a custom name for the QMI
> service identifier, use the one provided in qmi.h and remove the
> locally defined macro.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
> ---
> drivers/slimbus/qcom-ngd-ctrl.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v1 6/8] soc: qcom: pdr: Use the unified QMI service ID instead of defining it locally
From: Dmitry Baryshkov @ 2026-03-10 0:06 UTC (permalink / raw)
To: Daniel Lezcano
Cc: konradybcio, andersson, linux-kernel, Alex Elder, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jeff Johnson, Mathieu Poirier, Srinivas Kandagatla,
Jaroslav Kysela, Takashi Iwai, Kees Cook, Greg Kroah-Hartman,
Arnd Bergmann, Mark Brown, Wesley Cheng, netdev, linux-wireless,
ath10k, ath11k, ath12k, linux-arm-msm, linux-remoteproc,
linux-sound
In-Reply-To: <20260309230346.3584252-7-daniel.lezcano@oss.qualcomm.com>
On Tue, Mar 10, 2026 at 12:03:35AM +0100, Daniel Lezcano wrote:
> Instead of defining a local macro with a custom name for the QMI
> service identifier, use the one provided in qmi.h and remove the
> locally defined macro.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
> ---
> drivers/soc/qcom/pdr_interface.c | 4 ++--
> drivers/soc/qcom/pdr_internal.h | 3 ---
> drivers/soc/qcom/qcom_pd_mapper.c | 2 +-
> 3 files changed, 3 insertions(+), 6 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v1 7/8] ALSA: usb-audio: qcom: Use the unified QMI service ID instead of defining it locally
From: Dmitry Baryshkov @ 2026-03-10 0:07 UTC (permalink / raw)
To: Daniel Lezcano
Cc: konradybcio, andersson, linux-kernel, Alex Elder, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jeff Johnson, Mathieu Poirier, Srinivas Kandagatla,
Jaroslav Kysela, Takashi Iwai, Kees Cook, Greg Kroah-Hartman,
Arnd Bergmann, Mark Brown, Wesley Cheng, netdev, linux-wireless,
ath10k, ath11k, ath12k, linux-arm-msm, linux-remoteproc,
linux-sound, Erick Karanja
In-Reply-To: <20260309230346.3584252-8-daniel.lezcano@oss.qualcomm.com>
On Tue, Mar 10, 2026 at 12:03:36AM +0100, Daniel Lezcano wrote:
> Instead of defining a local macro with a custom name for the QMI
> service identifier, use the one provided in qmi.h and remove the
> locally defined macro.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
> ---
> sound/usb/qcom/qc_audio_offload.c | 2 +-
> sound/usb/qcom/usb_audio_qmi_v01.h | 1 -
> 2 files changed, 1 insertion(+), 2 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v1 8/8] samples: qmi: Use the unified QMI service ID instead of defining it locally
From: Dmitry Baryshkov @ 2026-03-10 0:07 UTC (permalink / raw)
To: Daniel Lezcano
Cc: konradybcio, andersson, linux-kernel, Alex Elder, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jeff Johnson, Mathieu Poirier, Srinivas Kandagatla,
Jaroslav Kysela, Takashi Iwai, Kees Cook, Greg Kroah-Hartman,
Arnd Bergmann, Mark Brown, Wesley Cheng, netdev, linux-wireless,
ath10k, ath11k, ath12k, linux-arm-msm, linux-remoteproc,
linux-sound
In-Reply-To: <20260309230346.3584252-9-daniel.lezcano@oss.qualcomm.com>
On Tue, Mar 10, 2026 at 12:03:37AM +0100, Daniel Lezcano wrote:
> Instead of defining a local macro with a custom name for the QMI
> service identifier, use the one provided in qmi.h and remove the
> locally defined macro.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
> ---
> samples/qmi/qmi_sample_client.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v1 0/8] Group QMI service IDs into the QMI header
From: Daniel Lezcano @ 2026-03-10 0:09 UTC (permalink / raw)
To: Jeff Johnson, konradybcio, andersson
Cc: linux-kernel, Alex Elder, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Jeff Johnson,
Mathieu Poirier, Srinivas Kandagatla, Jaroslav Kysela,
Takashi Iwai, Kees Cook, Greg Kroah-Hartman, Arnd Bergmann,
Mark Brown, Wesley Cheng, netdev, linux-wireless, ath10k, ath11k,
ath12k, linux-arm-msm, linux-remoteproc, linux-sound
In-Reply-To: <9cc7638f-1232-4cb7-b4d7-cdac66a2f4ba@oss.qualcomm.com>
On 3/10/26 00:50, Jeff Johnson wrote:
> On 3/9/2026 4:03 PM, Daniel Lezcano wrote:
>> The different subsystems implementing the QMI service protocol are
>> using their own definition of the service id. It is not a problem but
>> it results on having those duplicated with different names but the
>> same value and without consistency in their name.
>>
>> It makes more sense to unify their names and move the definitions in
[ ... ]
> prefix for wireless drivers is simply wifi: <driver>:
> so s/net: drivers: wireless:/wifi:/
Noted, thanks
>> remoteproc: qcom: Use the unified QMI service ID instead of defining
>> it locally
>> slimbus: qcom-ngd-ctrl: Use the unified QMI service ID instead of
>> defining it locally
>> soc: qcom: pdr: Use the unified QMI service ID instead of defining it
>> locally
>> ALSA: usb-audio: qcom: Use the unified QMI service ID instead of
>> defining it locally
>> samples: qmi: Use the unified QMI service ID instead of defining it
>> locally
>>
>> drivers/net/ipa/ipa_qmi.c | 6 ++----
>> drivers/net/wireless/ath/ath10k/qmi.c | 2 +-
>> drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.h | 1 -
>> drivers/net/wireless/ath/ath11k/qmi.c | 2 +-
>> drivers/net/wireless/ath/ath11k/qmi.h | 1 -
>> drivers/net/wireless/ath/ath12k/qmi.c | 2 +-
>> drivers/net/wireless/ath/ath12k/qmi.h | 1 -
>> drivers/remoteproc/qcom_sysmon.c | 2 +-
>> drivers/slimbus/qcom-ngd-ctrl.c | 5 ++---
>> drivers/soc/qcom/pdr_interface.c | 4 ++--
>> drivers/soc/qcom/pdr_internal.h | 3 ---
>> drivers/soc/qcom/qcom_pd_mapper.c | 2 +-
>> include/linux/soc/qcom/qmi.h | 12 ++++++++++++
>> samples/qmi/qmi_sample_client.c | 2 +-
>> sound/usb/qcom/qc_audio_offload.c | 2 +-
>> sound/usb/qcom/usb_audio_qmi_v01.h | 1 -
>
> You are touching a lot of subsystems with a single series.
> How do you plan on having these land?
> Do you have a maintainer who will take all of these through their tree?
Yes I thought Bjorn or Konrad would take them with the acked-by from the
different subsystems
^ permalink raw reply
* Re: [PATCH v1 0/8] Group QMI service IDs into the QMI header
From: Dmitry Baryshkov @ 2026-03-10 0:11 UTC (permalink / raw)
To: Daniel Lezcano
Cc: konradybcio, andersson, linux-kernel, Alex Elder, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jeff Johnson, Mathieu Poirier, Srinivas Kandagatla,
Jaroslav Kysela, Takashi Iwai, Kees Cook, Greg Kroah-Hartman,
Arnd Bergmann, Mark Brown, Wesley Cheng, netdev, linux-wireless,
ath10k, ath11k, ath12k, linux-arm-msm, linux-remoteproc,
linux-sound
In-Reply-To: <20260309230346.3584252-1-daniel.lezcano@oss.qualcomm.com>
On Tue, Mar 10, 2026 at 12:03:29AM +0100, Daniel Lezcano wrote:
> The different subsystems implementing the QMI service protocol are
> using their own definition of the service id. It is not a problem but
> it results on having those duplicated with different names but the
> same value and without consistency in their name.
>
> It makes more sense to unify their names and move the definitions in
> the QMI header file providing a consistent way to represent the
> supported protocols. Consequently the different drivers will use them
> instead of their own definition of the service id.
Also this looks like a first step towards providing qrtr service debugfs
in the kernel.
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [BUG] wifi: mt76: mt7925u: probe with driver mt7925u failed with error -110
From: Nick @ 2026-03-10 0:30 UTC (permalink / raw)
To: Sean Wang
Cc: linux-wireless, Felix Fietkau, Lorenzo Bianconi, Ryder Lee,
Shayne Chen, Sean Wang, Deren Wu, Leon Yen
In-Reply-To: <CAGp9Lzp2s675kmTJG+iYgLXS=fjiD-JC6GYjom7i-bcWFDxWoQ@mail.gmail.com>
On Fri, Mar 6, 2026 at 6:46 PM Sean Wang <sean.wang@kernel.org> wrote:
>
> Hi Nick,
>
> Thanks for the detailed report this is very helpful. I don't have an
> MT7925 USB device to detail look into the issue, but based on the
> trace I wrote a small change to try a different MT7925 reset sequence.
> please help test.
>
> --- a/drivers/net/wireless/mediatek/mt76/mt792x_usb.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt792x_usb.c
> @@ -234,6 +234,36 @@ int mt792xu_dma_init(struct mt792x_dev *dev, bool resume)
> }
> EXPORT_SYMBOL_GPL(mt792xu_dma_init);
>
> +static int mt7925u_wfsys_reset(struct mt792x_dev *dev)
> +{
> + u32 val;
> + int i;
> +
> +#define MT7925_CBTOP_RGU_WF_SUBSYS_RST 0x70028600
> +#define MT7925_WFSYS_SW_INIT_DONE_ADDR 0x184c1604
> +#define MT7925_WFSYS_SW_INIT_DONE 0x00001d1e
> +
> + val = mt792xu_uhw_rr(&dev->mt76, MT7925_CBTOP_RGU_WF_SUBSYS_RST);
> + val |= MT_CBTOP_RGU_WF_SUBSYS_RST_WF_WHOLE_PATH;
> + mt792xu_uhw_wr(&dev->mt76, MT7925_CBTOP_RGU_WF_SUBSYS_RST, val);
> +
> + msleep(20);
> +
> + val = mt792xu_uhw_rr(&dev->mt76, MT7925_CBTOP_RGU_WF_SUBSYS_RST);
> + val &= ~MT_CBTOP_RGU_WF_SUBSYS_RST_WF_WHOLE_PATH;
> + mt792xu_uhw_wr(&dev->mt76, MT7925_CBTOP_RGU_WF_SUBSYS_RST, val);
> +
> + for (i = 0; i < MT792x_WFSYS_INIT_RETRY_COUNT; i++) {
> + val = mt792xu_uhw_rr(&dev->mt76, MT7925_WFSYS_SW_INIT_DONE_ADDR);
> + if (val == MT7925_WFSYS_SW_INIT_DONE)
> + return 0;
> +
> + msleep(100);
> + }
> +
> + return -ETIMEDOUT;
> +}
> +
> int mt792xu_wfsys_reset(struct mt792x_dev *dev)
> {
> u32 val;
> @@ -241,6 +271,9 @@ int mt792xu_wfsys_reset(struct mt792x_dev *dev)
>
> mt792xu_epctl_rst_opt(dev, false);
>
> + if (is_mt7925(&dev->mt76))
> + return mt7925u_wfsys_reset(dev);
> +
> val = mt792xu_uhw_rr(&dev->mt76, MT_CBTOP_RGU_WF_SUBSYS_RST);
>
>
Sean,
Testing complete. Results are good. You can show the following:
Tested-by: Nick Morrow <morrownr@gmail.com>
Tested-by: Satadru Pramanik <satadru@gmail.com>
Thank you for working on this issue. If it is possible for your patch to go
directly in to be in one of the next rc's, that would be great and setting
it to backport would also be much appreciated.
Nick Morrow
> On Fri, Mar 6, 2026 at 1:24 PM Nick <morrownr@gmail.com> wrote:
> >
> > > > Reference: https://github.com/morrownr/USB-WiFi/issues/688#issuecomment-3999038526
> > > >
> > > > The above thread is rather lengthy as we have been working on this
> > > > issue since Dec. 25.
> > > >
> > > > Testing with a Netgear A9000 USB WiFi adapter (mt7925u driver). Kernel
> > > > 7.0 rc2 and a x86_64 system. Additional testing with older kernels was
> > > > also performed with the same results.
> > > >
> > > > Problem description:
> > > >
> > > > Cold boot shows the adapter coming up and operating normally.
> > > >
> > > > Removing the adapter from the USB port and replacing it shows the
> > > > adapter coming up and operating normally.
> > > >
> > > > A warm reboot does not provide a WiFi interface and shows the
> > > > following in the system log:
> > > >
> > > > mt7925u 2-3.2:1.0: probe with driver mt7925u failed with error -110
> > > >
> > > > Using the commands rmmod and modeprobe do not provide a WiFi interface.
> > > >
> > > > Thoughts: The problem likely is not the module teardown. The problem
> > > > seems to be that the firmware (or the mt7925u driver) leaves the
> > > > adapter in a strange state such that a power cycle of the adapter
> > > > hardware is needed before the mt7925u driver can properly initialize
> > > > it a second time.
> > > >
> > >
> > > Hi Nick,
> > >
> > > Could you enable debug logs and check whether the driver can still
> > > read the correct chip ID after a warm reboot, and at which step the
> > > initialization fails before the -110 error? Thanks for continuing to
> > > test and gather this useful information.
> > >
> > > Sean
> >
> > Hi Sean,
> >
> > Github user @exct has performed the testing requested and provides the
> > following report:
> >
> > mt7925u Probe Failure Debug Report
> > Adapter: Netgear A9000 (USB ID 0846:9072, MediaTek MT7925)
> > Kernel: 6.19.6-2-cachyos
> >
> > Summary
> > The driver can read the correct chip ID after a warm reload. The
> > failure occurs before firmware is loaded, inside
> > mt792xu_wfsys_reset(), which times out waiting for the WiFi subsystem
> > to reinitialize. -ETIMEDOUT (-110) is returned and the probe aborts.
> >
> > Findings
> >
> > Question: Chip ID readable after warm reload?
> > Answer: Yes — MT_HW_CHIPID = 0x7925, MT_HW_REV = 0x8a00
> >
> > Question: Which step fails?
> > Answer: mt792xu_wfsys_reset() — WFSYS_INIT_DONE never asserted
> >
> > Question: Does it reach mt792xu_mcu_power_on()?
> > Answer: No
> >
> > Question: Does it reach mt7925_run_firmware()?
> > Answer: No
> >
> > Probe Sequence Trace
> >
> > mt7925u_probe()
> > ├─ mt76_alloc_device() OK
> > ├─ __mt76u_init() OK
> > ├─ read MT_HW_CHIPID (0x70010200) → 0x00007925 ✓
> > ├─ read MT_HW_REV (0x70010204) → 0x00008a00 ✓
> > ├─ read MT_CONN_ON_MISC (0x7c0600f0) → 0x00000003 ← FW_N9_RDY is SET
> > ├─ enters mt792xu_wfsys_reset() ← triggered because FW_N9_RDY = 1
> > │ ├─ write MT_CBTOP_RGU_WF_SUBSYS_RST (assert reset)
> > │ ├─ write MT_CBTOP_RGU_WF_SUBSYS_RST (deassert reset)
> > │ ├─ poll MT_UDMA_CONN_INFRA_STATUS (0x74000a20) → 0x00000000
> > │ ├─ poll MT_UDMA_CONN_INFRA_STATUS (0x74000a20) → 0x00000000
> > │ └─ ... timeout after ~212 ms → return -ETIMEDOUT
> > └─ goto error: (mt76u_queues_deinit + mt76_free_device)
> >
> > Root Cause
> >
> > After rmmod, the firmware leaves FW_N9_RDY asserted in
> > MT_CONN_ON_MISC. On re-probe, the driver correctly detects this and
> > calls mt792xu_wfsys_reset() to recover. However, the WiFi subsystem
> > never signals completion — WFSYS_INIT_DONE in
> > MT_UDMA_CONN_INFRA_STATUS (reg 0x74000a20) stays 0x00000000 throughout
> > the retry loop. The subsystem is stuck in a state that the software
> > reset path cannot recover from. Only a full USB power cycle clears it.
> >
> > Hope this helps,
> >
> > Nick
^ permalink raw reply
* Re: [PATCHv2 wireless-next] wifi: brcmsmac: use FAM for debug code
From: Julian Calaby @ 2026-03-10 1:11 UTC (permalink / raw)
To: Arend van Spriel
Cc: linux-wireless, Rosen Penev,
open list:BROADCOM BRCM80211 IEEE802.11 WIRELESS DRIVERS,
open list:BROADCOM BRCM80211 IEEE802.11 WIRELESS DRIVERS,
open list
In-Reply-To: <20260309215907.5789-1-rosenp@gmail.com>
Hi Arend,
On Tue, Mar 10, 2026 at 8:59 AM Rosen Penev <rosenp@gmail.com> wrote:
>
> Debug code requires a separate allocation to duplicate a string. A FAM
> allows properly sized allocation with a single kfree.
Sorry Rosen for hijacking your patch here.
With these changes, does allocating and copying the string really need
to be behind a DEBUG ifdef?
The allocation, copying and freeing of the memory isn't in a hot path,
so allocating/freeing a couple more bytes shouldn't matter that much,
which only leaves the memory footprint, which appears to be less than
10 bytes.
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* Re: [PATCHv2 wireless-next] wifi: brcmsmac: use FAM for debug code
From: Rosen Penev @ 2026-03-10 1:47 UTC (permalink / raw)
To: Julian Calaby
Cc: Arend van Spriel, linux-wireless,
open list:BROADCOM BRCM80211 IEEE802.11 WIRELESS DRIVERS,
open list:BROADCOM BRCM80211 IEEE802.11 WIRELESS DRIVERS,
open list
In-Reply-To: <CAGRGNgUsVxecZobcXvVwmaHD+QHmzp4qTPGSLOpJb6Uinrpa+w@mail.gmail.com>
On Mon, Mar 9, 2026 at 6:11 PM Julian Calaby <julian.calaby@gmail.com> wrote:
>
> Hi Arend,
>
> On Tue, Mar 10, 2026 at 8:59 AM Rosen Penev <rosenp@gmail.com> wrote:
> >
> > Debug code requires a separate allocation to duplicate a string. A FAM
> > allows properly sized allocation with a single kfree.
>
> Sorry Rosen for hijacking your patch here.
>
> With these changes, does allocating and copying the string really need
> to be behind a DEBUG ifdef?
I don't know. I didn't write this code.
>
> The allocation, copying and freeing of the memory isn't in a hot path,
> so allocating/freeing a couple more bytes shouldn't matter that much,
> which only leaves the memory footprint, which appears to be less than
> 10 bytes.
>
> Thanks,
>
> --
> Julian Calaby
>
> Email: julian.calaby@gmail.com
> Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* RE: [BUG] wifi: rtw88: Hard system freeze on RTL8821CE when power_save is enabled (LPS/ASPM conflict)
From: Ping-Ke Shih @ 2026-03-10 2:02 UTC (permalink / raw)
To: LB F; +Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <CALdGYqSQ1Ko2TTBhUizMu_FvLMUAuQfFrVwS10n_C-LSQJQQkQ@mail.gmail.com>
LB F <goainwo@gmail.com> wrote:
> Hi Ping-Ke,
>
> I am writing to formally report a critical bug that causes a hard
> system freeze on laptops equipped with the RTL8821CE WiFi module, and
> to propose solutions.
>
> Description:
> On an HP laptop equipped with a Realtek RTL8821CE 802.11ac PCIe
> adapter (PCI ID: 10ec:c821), the system experiences a hard lockup
> (complete freeze of the UI and kernel, sysrq doesn't work, requires
> holding the power button) when the WiFi adapter enters the power
> saving state.
>
> This issue occurs consistently across multiple Linux distributions and
> kernel versions (reproduced on upstream kernel 6.13 and 6.19-rc).
>
> Steps to Reproduce:
> 1. Use a system with RTL8821CE (pci:10ec:c821).
> 2. Ensure NetworkManager is configured with wifi.powersave = 3 (or
> power saving is enabled via TLP/iw).
> 3. Connect to a WiFi network and let the system idle.
> 4. The system will eventually freeze completely.
Can you dig kernel log (by netconsole or ramoops) if something useful?
I'd like to know this is hardware level freeze or kernel can capture
something wrong.
>
> Workarounds that successfully prevent the freeze:
> * Passing disable_lps_deep=y to rtw88_core.
> * Passing disable_aspm=y to rtw88_pci (or pcie_aspm=off).
> * Disabling WiFi power save via NetworkManager.
Are these totally needed to workaround the problem? Or disable_aspm is
enough?
I'd list them in order of power consumption impact: (the topmost is lower impact)
1. disable_aspm=y
2. disable_lps_deep=y
3. disable WiFi power save
If you can do experiments on your platform, we can be easier to decide
which workarounds are adopted.
>
> Technical Analysis:
> The root cause appears to be an unhandled race condition or hardware
> bug between the adapter's Low Power State (LPS) Deep mode
> (LPS_DEEP_MODE_LCLK) and the PCIe Active State Power Management (ASPM
> L1) mechanism.
>
> When the firmware drops into LPS_DEEP_MODE_LCLK concurrently with the
> PCIe bus entering ASPM L1, the chip fails to handle PCIe Wake
> signaling correctly. While there is an existing workaround in
> rtw_pci_napi_poll (pci.c:1806) that sets `rtwpci->rx_no_aspm = true`
> during NAPI poll for 8821CE, this polling wrapper is insufficient. The
> deadlock often occurs during idle states when polling isn't actively
> disabling ASPM, but the system suddenly needs to wake the radio.
`rtwpci->rx_no_aspm = true` was another workaround years ago on certain
platform. I'd say ASPM has many interoperability problems, even years ago.
But what does 'deadlock' mean? As I know NAPI poll is scheduled by ISR,
and going to receive packets. The rx_no_aspm workaround is to forcely turn
off ASPM during this period.
>
> Proposed Solutions:
> Given that LPS_DEEP_MODE_LCLK seems fundamentally unreliable on 8821ce
> PCIe variants when paired with standard Windows-era ASPM
> implementations on laptops (HP, Lenovo, ASUS are all affected), the
> most robust solution is to strip the unsupported deep sleep flag from
> the hardware spec.
>
> ```diff
> --- a/drivers/net/wireless/realtek/rtw88/rtw8821c.c
> +++ b/drivers/net/wireless/realtek/rtw88/rtw8821c.c
> @@ -1999,7 +1999,7 @@ struct rtw_chip_info rtw8821c_hw_spec = {
> .bt_supported = true,
> .fbtc_has_ext_ctrl = true,
> .coex_info_hw_supported = true,
> - .lps_deep_mode_supported = BIT(LPS_DEEP_MODE_LCLK),
> + .lps_deep_mode_supported = 0, /* Disabled due to ASPM L1 hard locks */
> .dpk_supported = true,
> .pstdma_type = COEX_PSTDMA_FORCE_LPSOFF,
> .bfee_support = false,
> ```
>
> Alternatively, a PCI Subsystem-based quirk should be introduced in
> rtw_pci_aspm_set() to refuse ASPM BIT_L1_SW_EN transitions for
> affected hardware IDs, similar to how CLKREQ issues are handled for
> 8822C via efuse->rfe_option.
I'd add a quirk to your platforms, so other platforms can still have
better power consumption.
>
> Cross-Reference Analysis of other RTL8821CE Bugs:
> After aggregating recent open bug reports for the 8821ce chip on
> Bugzilla (https://bugzilla.kernel.org), it is apparent that almost all
> of them are victims of the exact same underlying race condition.
> 1. Bug 215131: System freeze preceded by 'pci bus timeout, check dma
> status'. Workaround used: disable_aspm=1.
> 2. Bug 219830: Log shows 'firmware failed to leave lps state' and
> 'failed to send h2c command'. A direct smoking gun for LPS Deep mode
> freezing.
> 3. Bug 218697 & Bug 217491: Endless 'timed out to flush queue' floods.
> 4. Bug 217781 & Bug 216685: Random dropouts and low wireless speed.
>
> Given the volume and age of these unresolved reports, disabling
> .lps_deep_mode_supported (or restricting ASPM L1) specifically for
> 10ec:c821 is desperately needed.
>
> System Information:
> - Hardware: HP Notebook (SKU: P3S95EA#ACB, Family: 103C_5335KV)
> - CPU: Intel Core i3-5005U
> - WiFi PCI ID: 10ec:c821, Subsystem: 103c:831a
> - Kernel: 6.13 / 6.19
> - Driver module: rtw88_8821ce
>
> I am happy to test any patches provided or formally submit the patch
> above if maintainers agree it is the right approach. Thank you!
We have not modified RTL8821CE for a long time, so I'd add workaround
to specific platform as mentioned above.
Ping-Ke
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: avoid dynamic alloc when parsing wmi tb
From: Baochen Qiang @ 2026-03-10 2:05 UTC (permalink / raw)
To: Nicolas Escande, ath12k; +Cc: linux-wireless
In-Reply-To: <20260309152050.191820-1-nico.escande@gmail.com>
On 3/9/2026 11:20 PM, Nicolas Escande wrote:
> On each WMI message received from the hardware, we alloc a temporary array
> of WMI_TAG_MAX entries of type void *. This array is then populated with
> pointers of parsed structs depending on the WMI type, and then freed. This
> alloc can fail when memory pressure in the system is high enough.
>
> Given the fact that it is scheduled in softirq with the system_bh_wq, we
> should not be able to parse more than one WMI message per CPU at any time
>
> So instead lets move to a per cpu allocated array, stored in the struct
> ath12k_base, that is reused accros calls. The ath12k_wmi_tlv_parse_alloc()
> is also renamed into / merged with ath12k_wmi_tlv_parse() as it no longer
> allocs memory but returns the existing per-cpu one.
>
> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00218-QCAHKSWPL_SILICONZ-1
>
> Signed-off-by: Nicolas Escande <nico.escande@gmail.com>
> ---
> changes from RFC:
> - rebased on ath-next 8e0ab5b9adb7
> - converted missing call sites ath12k_wmi_obss_color_collision_event()
> & ath12k_wmi_pdev_temperature_event()
> - changed alloc order & cleanup path in ath12k_core_alloc() as it seems
> it confused people
> - used sizeof(*tb) in ath12k_wmi_tlv_parse()
>
> Note I did try to move to a DEFINE_PER_CPU() allocated array but the module
> loader complained about the array size. So I stuck to the per ab alloc.
> ---
> drivers/net/wireless/ath/ath12k/core.c | 7 +
> drivers/net/wireless/ath/ath12k/core.h | 2 +
> drivers/net/wireless/ath/ath12k/wmi.c | 178 ++++++-------------------
> 3 files changed, 51 insertions(+), 136 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath12k/core.c b/drivers/net/wireless/ath/ath12k/core.c
> index c31c47fb5a73..c1de70b24828 100644
> --- a/drivers/net/wireless/ath/ath12k/core.c
> +++ b/drivers/net/wireless/ath/ath12k/core.c
> @@ -2258,6 +2258,7 @@ void ath12k_core_free(struct ath12k_base *ab)
> timer_delete_sync(&ab->rx_replenish_retry);
> destroy_workqueue(ab->workqueue_aux);
> destroy_workqueue(ab->workqueue);
> + free_percpu(ab->wmi_tb);
> kfree(ab);
> }
>
> @@ -2270,6 +2271,11 @@ struct ath12k_base *ath12k_core_alloc(struct device *dev, size_t priv_size,
> if (!ab)
> return NULL;
>
> + ab->wmi_tb = __alloc_percpu(WMI_TAG_MAX * sizeof(void *),
> + __alignof__(void *));
> + if (!ab->wmi_tb)
> + goto err_sc_free;
> +
> init_completion(&ab->driver_recovery);
>
> ab->workqueue = create_singlethread_workqueue("ath12k_wq");
> @@ -2317,6 +2323,7 @@ struct ath12k_base *ath12k_core_alloc(struct device *dev, size_t priv_size,
> err_free_wq:
> destroy_workqueue(ab->workqueue);
> err_sc_free:
> + free_percpu(ab->wmi_tb);
> kfree(ab);
> return NULL;
> }
> diff --git a/drivers/net/wireless/ath/ath12k/core.h b/drivers/net/wireless/ath/ath12k/core.h
> index 59c193b24764..ebe7b94fd712 100644
> --- a/drivers/net/wireless/ath/ath12k/core.h
> +++ b/drivers/net/wireless/ath/ath12k/core.h
> @@ -19,6 +19,7 @@
> #include <linux/average.h>
> #include <linux/of.h>
> #include <linux/rhashtable.h>
> +#include <linux/percpu.h>
> #include "qmi.h"
> #include "htc.h"
> #include "wmi.h"
> @@ -937,6 +938,7 @@ struct ath12k_base {
> struct device *dev;
> struct ath12k_qmi qmi;
> struct ath12k_wmi_base wmi_ab;
> + void __percpu *wmi_tb;
any reason why my v1 suggestion is not considered?
instead of allocating it per device, how about making it global and define/allocate once
when loading driver. This way we may save some memory in case where more than one devices
get probed?
^ permalink raw reply
* [PATCH] wifi: ath12k: fix use-after-free of arvif in assign_vif_chanctx()
From: James Kim @ 2026-03-10 2:43 UTC (permalink / raw)
To: jjohnson
Cc: quic_srirrama, quic_ramess, kvalo, stable, linux-wireless, ath12k,
linux-kernel, James Kim
In ath12k_mac_op_assign_vif_chanctx(), arvif is obtained from
ath12k_mac_assign_link_vif() and then passed to
ath12k_mac_assign_vif_to_vdev(). Inside that function, when the
target radio (ar) differs from arvif->ar (multi-radio configuration),
the old arvif is freed via ath12k_mac_unassign_link_vif() -> kfree()
and a new one is allocated internally. However, only the ar pointer
is returned to the caller — the caller's arvif still points to the
freed memory.
The caller then continues to dereference this stale arvif pointer
at multiple locations (arvif->vdev_id, arvif->punct_bitmap,
arvif->is_started, etc.), resulting in a use-after-free.
Fix this by re-fetching arvif from ahvif->link[link_id] after
ath12k_mac_assign_vif_to_vdev() returns, since the link pointer
is always updated when a new arvif is assigned.
Fixes: 477cabfdb776 ("wifi: ath12k: modify link arvif creation and removal for MLO")
Cc: stable@vger.kernel.org
Signed-off-by: James Kim <james010kim@gmail.com>
---
drivers/net/wireless/ath/ath12k/mac.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
index b253d1e3f405..ee44a8b59e9b 100644
--- a/drivers/net/wireless/ath/ath12k/mac.c
+++ b/drivers/net/wireless/ath/ath12k/mac.c
@@ -12069,6 +12069,17 @@ ath12k_mac_op_assign_vif_chanctx(struct ieee80211_hw *hw,
return -EINVAL;
}
+ /* ath12k_mac_assign_vif_to_vdev() may free and reassign arvif
+ * internally when switching radios (ar != arvif->ar). Refresh
+ * arvif from ahvif->link[].
+ */
+ arvif = wiphy_dereference(hw->wiphy, ahvif->link[link_id]);
+ if (!arvif) {
+ ath12k_hw_warn(ah, "failed to get arvif for link %u after vdev assignment",
+ link_id);
+ return -ENOENT;
+ }
+
ab = ar->ab;
ath12k_dbg(ab, ATH12K_DBG_MAC,
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 02/14] firmware: qcom: Add a generic PAS service
From: Sumit Garg @ 2026-03-10 4:58 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-arm-msm, devicetree, dri-devel, freedreno, linux-media,
netdev, linux-wireless, ath12k, linux-remoteproc, andersson,
konradybcio, robh, krzk+dt, conor+dt, robin.clark, sean, akhilpo,
lumag, abhinav.kumar, jesszhan0024, marijn.suijten, airlied,
simona, vikash.garodia, dikshita.agarwal, bod, mchehab, elder,
andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
mathieu.poirier, trilokkumar.soni, mukesh.ojha, pavan.kondeti,
jorge.ramirez, tonyh, vignesh.viswanathan, srinivas.kandagatla,
amirreza.zarrabi, jens.wiklander, op-tee, apurupa, skare,
Sumit Garg
In-Reply-To: <aa5z23EtUF9k1MTy@sumit-xelite>
On Mon, Mar 09, 2026 at 12:46:43PM +0530, Sumit Garg wrote:
> On Mon, Mar 09, 2026 at 08:10:02AM +0100, Krzysztof Kozlowski wrote:
> > On 09/03/2026 05:55, Sumit Garg wrote:
> > > On Fri, Mar 06, 2026 at 12:15:01PM +0100, Krzysztof Kozlowski wrote:
> > >> On 06/03/2026 11:50, Sumit Garg wrote:
> > >>> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > >>>
> > >>> Qcom platforms has the legacy of using non-standard SCM calls
> > >>> splintered over the various kernel drivers. These SCM calls aren't
> > >>> compliant with the standard SMC calling conventions which is a
> > >>> prerequisite to enable migration to the FF-A specifications from
> > >>> Arm.
> > >>>
> > >>> OP-TEE as an alternative trusted OS to QTEE can't support these non-
> > >>> standard SCM calls. And even for newer architectures QTEE won't be able
> > >>> to support SCM calls either with FF-A requirements coming in. And with
> > >>> both OP-TEE and QTEE drivers well integrated in the TEE subsystem, it
> > >>> makes further sense to reuse the TEE bus client drivers infrastructure.
> > >>>
> > >>> The added benefit of TEE bus infrastructure is that there is support
> > >>> for discoverable/enumerable services. With that client drivers don't
> > >>> have to manually invoke a special SCM call to know the service status.
> > >>>
> > >>> So enable the generic Peripheral Authentication Service (PAS) provided
> > >>> by the firmware. It acts as the common layer with different TZ
> > >>> backends plugged in whether it's an SCM implementation or a proper
> > >>> TEE bus based PAS service implementation.
> > >>>
> > >>> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > >>> ---
> > >>> drivers/firmware/qcom/Kconfig | 8 +
> > >>> drivers/firmware/qcom/Makefile | 1 +
> > >>> drivers/firmware/qcom/qcom_pas.c | 295 +++++++++++++++++++++++++
> > >>> drivers/firmware/qcom/qcom_pas.h | 53 +++++
> > >>> include/linux/firmware/qcom/qcom_pas.h | 41 ++++
> > >>> 5 files changed, 398 insertions(+)
> > >>> create mode 100644 drivers/firmware/qcom/qcom_pas.c
> > >>> create mode 100644 drivers/firmware/qcom/qcom_pas.h
> > >>> create mode 100644 include/linux/firmware/qcom/qcom_pas.h
> > >>>
> > >>> diff --git a/drivers/firmware/qcom/Kconfig b/drivers/firmware/qcom/Kconfig
> > >>> index b477d54b495a..8653639d06db 100644
> > >>> --- a/drivers/firmware/qcom/Kconfig
> > >>> +++ b/drivers/firmware/qcom/Kconfig
> > >>> @@ -6,6 +6,14 @@
> > >>>
> > >>> menu "Qualcomm firmware drivers"
> > >>>
> > >>> +config QCOM_PAS
> > >>> + tristate
> > >>> + help
> > >>> + Enable the generic Peripheral Authentication Service (PAS) provided
> > >>> + by the firmware. It acts as the common layer with different TZ
> > >>> + backends plugged in whether it's an SCM implementation or a proper
> > >>> + TEE bus based PAS service implementation.
> > >>> +
> > >>> config QCOM_SCM
> > >>> select QCOM_TZMEM
> > >>> tristate
> > >>> diff --git a/drivers/firmware/qcom/Makefile b/drivers/firmware/qcom/Makefile
> > >>> index 0be40a1abc13..dc5ab45f906a 100644
> > >>> --- a/drivers/firmware/qcom/Makefile
> > >>> +++ b/drivers/firmware/qcom/Makefile
> > >>> @@ -8,3 +8,4 @@ qcom-scm-objs += qcom_scm.o qcom_scm-smc.o qcom_scm-legacy.o
> > >>> obj-$(CONFIG_QCOM_TZMEM) += qcom_tzmem.o
> > >>> obj-$(CONFIG_QCOM_QSEECOM) += qcom_qseecom.o
> > >>> obj-$(CONFIG_QCOM_QSEECOM_UEFISECAPP) += qcom_qseecom_uefisecapp.o
> > >>> +obj-$(CONFIG_QCOM_PAS) += qcom_pas.o
> > >>> diff --git a/drivers/firmware/qcom/qcom_pas.c b/drivers/firmware/qcom/qcom_pas.c
> > >>> new file mode 100644
> > >>> index 000000000000..dc04ff1b6be0
> > >>> --- /dev/null
> > >>> +++ b/drivers/firmware/qcom/qcom_pas.c
> > >>> @@ -0,0 +1,295 @@
> > >>> +// SPDX-License-Identifier: GPL-2.0
> > >>> +/*
> > >>> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> > >>> + */
> > >>> +
> > >>> +#include <linux/delay.h>
> > >>> +#include <linux/device/devres.h>
> > >>> +#include <linux/firmware/qcom/qcom_pas.h>
> > >>> +#include <linux/of.h>
> > >>> +#include <linux/kernel.h>
> > >>> +#include <linux/module.h>
> > >>> +#include <linux/slab.h>
> > >>> +
> > >>> +#include "qcom_pas.h"
> > >>> +#include "qcom_scm.h"
> > >>> +
> > >>> +static struct qcom_pas_ops *ops_ptr;
> > >>
> > >> I really dislike this singleton design. And it is not even needed! If
> > >> you were storing here some allocated instance of SCM/PAS I could
> > >> understand, but singleton for only ops? Just implement one driver (so
> > >> SCM + whatever you have here) which will decide which ops to use,
> > >> through the probe. Really, this is neither needed nor beneficial.
> > >
> > > The motivation here is rather quite opposite to the single monolithic
> > > SCM driver design. The TZ services like PAS, ICE and so on are going to
> > > be implemented as independent discoverable devices on TEE bus which
> > > rather needs independent kernel client drivers.
> >
> > You still have singleton here. So if you think you do opposite to
> > singleton, then drop this static.
>
> Sure.
>
> >
> > >
> > > Also, the single driver probe can't work here since the SCM driver is
> > > bound to the platform bus whereas the TEE PAS driver is bound to the TEE
> > > bus. So there is a reason for the current design.
> > >
> > >>
> > >> It actually leads to more problems with this barrier handling, see
> > >> further comments.
> > >
> > > The barrier handling is something that I carried over from existing
> > > implmentation but I can't see a reason why it can't be replaced with a
> > > simple mutex. See diff below for mutex.
> > >
> > >> ...
> > >>
> > >>> +
> > >>> +/**
> > >>> + * qcom_pas_shutdown() - Shut down the remote processor
> > >>> + * @pas_id: peripheral authentication service id
> > >>> + *
> > >>> + * Returns 0 on success.
> > >>> + */
> > >>> +int qcom_pas_shutdown(u32 pas_id)
> > >>> +{
> > >>> + if (ops_ptr)
> > >>> + return ops_ptr->shutdown(ops_ptr->dev, pas_id);
> > >>> +
> > >>> + return -ENODEV;
> > >>> +}
> > >>> +EXPORT_SYMBOL_GPL(qcom_pas_shutdown);
> > >>> +
> > >>> +/**
> > >>> + * qcom_pas_supported() - Check if the peripheral authentication service is
> > >>> + * available for the given peripheral
> > >>> + * @pas_id: peripheral authentication service id
> > >>> + *
> > >>> + * Returns true if PAS is supported for this peripheral, otherwise false.
> > >>> + */
> > >>> +bool qcom_pas_supported(u32 pas_id)
> > >>> +{
> > >>> + if (ops_ptr)
> > >>
> > >> Lack of barriers here is not looking right. Existing/old code is not a
> > >> good example, I fixed only the obvious issue, but new code should be
> > >> correct from the beginning.
> > >>
> > >> Barriers should normally be always paired, unless you have some clear
> > >> path no concurrent execution can happen here, but such explanation is
> > >> missing, look:
> > >
> > > Actually concurrent execution is rather required here since TZ can
> > > support parallel bring-up of co-processors. The synchonization is only
> > > needed when PAS client drivers are performing a deferred probe waiting
> > > for the service to be available. However, you are right explanation is
> > > missing here which I will add in the next version.
> >
> > Hm? Existing comments are completely useless. Your comment said just
> > "barrier" basically... That's nothing useful.
>
> Agree, following is something I plan for v2 (using mutex instead of a
> barrier):
>
> /*
> * The ops mutex here is only intended to synchronize when client drivers
> * are in parallel checking for PAS service availability. However, once the
> * PAS backend becomes available, it is allowed for multiple threads to enter
> * TZ for parallel bringup of co-processors during boot.
> */
> static DEFINE_MUTEX(ops_mutex);
After more testing, it came out that there are corner cases where the
registered ops structure writes aren't visible to other cores. So indeed
a data barrier is needed instead of mutex. I will add relevant code
comments.
-Sumit
^ permalink raw reply
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