linux-toradex.git/drivers/soc/qcom/qmi_interface.c, branch v6.19 Linux kernel for Apalis and Colibri modules soc: qcom: fix endianness for QMI header 2025-06-17T20:49:10+00:00 Alexander Wilhelm alexander.wilhelm@westermo.com 2025-05-22T14:35:30+00:00 07a4688833b237331e5045f90fc546c085b28c86 The members of QMI header have to be swapped on big endian platforms. Use __le16 types instead of u16 ones. Signed-off-by: Alexander Wilhelm <alexander.wilhelm@westermo.com> Fixes: 9b8a11e82615 ("soc: qcom: Introduce QMI encoder/decoder") Fixes: 3830d0771ef6 ("soc: qcom: Introduce QMI helpers") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250522143530.3623809-3-alexander.wilhelm@westermo.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> 
The members of QMI header have to be swapped on big endian platforms. Use
__le16 types instead of u16 ones.

Signed-off-by: Alexander Wilhelm <alexander.wilhelm@westermo.com>
Fixes: 9b8a11e82615 ("soc: qcom: Introduce QMI encoder/decoder")
Fixes: 3830d0771ef6 ("soc: qcom: Introduce QMI helpers")
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250522143530.3623809-3-alexander.wilhelm@westermo.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
soc: qcom: qmi: Reorganize kerneldoc parameter names 2024-10-01T03:03:48+00:00 Julia Lawall Julia.Lawall@inria.fr 2024-09-30T11:21:10+00:00 eea73fa08e69fec9cdc915592022bec6a9ac8ad7 Reorganize kerneldoc parameter names to match the parameter order in the function header. Problems identified using Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Link: https://lore.kernel.org/r/20240930112121.95324-25-Julia.Lawall@inria.fr Signed-off-by: Bjorn Andersson <andersson@kernel.org> 
Reorganize kerneldoc parameter names to match the parameter
order in the function header.

Problems identified using Coccinelle.

Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Link: https://lore.kernel.org/r/20240930112121.95324-25-Julia.Lawall@inria.fr
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
soc: qcom: Switch to EXPORT_SYMBOL_GPL() 2023-09-27T23:08:38+00:00 Unnathi Chalicheemala quic_uchalich@quicinc.com 2023-09-22T18:48:17+00:00 9b09c0f289c5a8fc5e9b0c1f3cd2766d33b910dc Switch to GPL version of EXPORT_SYMBOL for Qualcomm SoC drivers. Signed-off-by: Unnathi Chalicheemala <quic_uchalich@quicinc.com> Reviewed-by: Trilok Soni <quic_tsoni@quicinc.com> Link: https://lore.kernel.org/r/20230922184817.5183-1-quic_uchalich@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> 
Switch to GPL version of EXPORT_SYMBOL for Qualcomm SoC drivers.

Signed-off-by: Unnathi Chalicheemala <quic_uchalich@quicinc.com>
Reviewed-by: Trilok Soni <quic_tsoni@quicinc.com>
Link: https://lore.kernel.org/r/20230922184817.5183-1-quic_uchalich@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
soc: qcom: qmi: Use alloc_ordered_workqueue() to create ordered workqueues 2023-05-25T03:03:19+00:00 Tejun Heo tj@kernel.org 2023-04-21T02:50:38+00:00 56310520308ab863030e9baa9a8f63bb31c94e27 BACKGROUND ========== When multiple work items are queued to a workqueue, their execution order doesn't match the queueing order. They may get executed in any order and simultaneously. When fully serialized execution - one by one in the queueing order - is needed, an ordered workqueue should be used which can be created with alloc_ordered_workqueue(). However, alloc_ordered_workqueue() was a later addition. Before it, an ordered workqueue could be obtained by creating an UNBOUND workqueue with @max_active==1. This originally was an implementation side-effect which was broken by 4c16bd327c74 ("workqueue: restore WQ_UNBOUND/max_active==1 to be ordered"). Because there were users that depended on the ordered execution, 5c0338c68706 ("workqueue: restore WQ_UNBOUND/max_active==1 to be ordered") made workqueue allocation path to implicitly promote UNBOUND workqueues w/ @max_active==1 to ordered workqueues. While this has worked okay, overloading the UNBOUND allocation interface this way creates other issues. It's difficult to tell whether a given workqueue actually needs to be ordered and users that legitimately want a min concurrency level wq unexpectedly gets an ordered one instead. With planned UNBOUND workqueue updates to improve execution locality and more prevalence of chiplet designs which can benefit from such improvements, this isn't a state we wanna be in forever. This patch series audits all callsites that create an UNBOUND workqueue w/ @max_active==1 and converts them to alloc_ordered_workqueue() as necessary. WHAT TO LOOK FOR ================ The conversions are from alloc_workqueue(WQ_UNBOUND | flags, 1, args..) to alloc_ordered_workqueue(flags, args...) which don't cause any functional changes. If you know that fully ordered execution is not ncessary, please let me know. I'll drop the conversion and instead add a comment noting the fact to reduce confusion while conversion is in progress. If you aren't fully sure, it's completely fine to let the conversion through. The behavior will stay exactly the same and we can always reconsider later. As there are follow-up workqueue core changes, I'd really appreciate if the patch can be routed through the workqueue tree w/ your acks. Thanks. Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Andy Gross <agross@kernel.org> Cc: Bjorn Andersson <andersson@kernel.org> Cc: Konrad Dybcio <konrad.dybcio@linaro.org> Cc: linux-arm-msm@vger.kernel.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230421025046.4008499-15-tj@kernel.org 
BACKGROUND
==========

When multiple work items are queued to a workqueue, their execution order
doesn't match the queueing order. They may get executed in any order and
simultaneously. When fully serialized execution - one by one in the queueing
order - is needed, an ordered workqueue should be used which can be created
with alloc_ordered_workqueue().

However, alloc_ordered_workqueue() was a later addition. Before it, an
ordered workqueue could be obtained by creating an UNBOUND workqueue with
@max_active==1. This originally was an implementation side-effect which was
broken by 4c16bd327c74 ("workqueue: restore WQ_UNBOUND/max_active==1 to be
ordered"). Because there were users that depended on the ordered execution,
5c0338c68706 ("workqueue: restore WQ_UNBOUND/max_active==1 to be ordered")
made workqueue allocation path to implicitly promote UNBOUND workqueues w/
@max_active==1 to ordered workqueues.

While this has worked okay, overloading the UNBOUND allocation interface
this way creates other issues. It's difficult to tell whether a given
workqueue actually needs to be ordered and users that legitimately want a
min concurrency level wq unexpectedly gets an ordered one instead. With
planned UNBOUND workqueue updates to improve execution locality and more
prevalence of chiplet designs which can benefit from such improvements, this
isn't a state we wanna be in forever.

This patch series audits all callsites that create an UNBOUND workqueue w/
@max_active==1 and converts them to alloc_ordered_workqueue() as necessary.

WHAT TO LOOK FOR
================

The conversions are from

  alloc_workqueue(WQ_UNBOUND | flags, 1, args..)

to

  alloc_ordered_workqueue(flags, args...)

which don't cause any functional changes. If you know that fully ordered
execution is not ncessary, please let me know. I'll drop the conversion and
instead add a comment noting the fact to reduce confusion while conversion
is in progress.

If you aren't fully sure, it's completely fine to let the conversion
through. The behavior will stay exactly the same and we can always
reconsider later.

As there are follow-up workqueue core changes, I'd really appreciate if the
patch can be routed through the workqueue tree w/ your acks. Thanks.

Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Andy Gross <agross@kernel.org>
Cc: Bjorn Andersson <andersson@kernel.org>
Cc: Konrad Dybcio <konrad.dybcio@linaro.org>
Cc: linux-arm-msm@vger.kernel.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230421025046.4008499-15-tj@kernel.org
net/sock: Introduce trace_sk_data_ready() 2023-01-23T11:26:50+00:00 Peilin Ye peilin.ye@bytedance.com 2023-01-20T00:45:16+00:00 40e0b09081420853542571c38875b48b60404ebb As suggested by Cong, introduce a tracepoint for all ->sk_data_ready() callback implementations. For example: <...> iperf-609 [002] ..... 70.660425: sk_data_ready: family=2 protocol=6 func=sock_def_readable iperf-609 [002] ..... 70.660436: sk_data_ready: family=2 protocol=6 func=sock_def_readable <...> Suggested-by: Cong Wang <cong.wang@bytedance.com> Signed-off-by: Peilin Ye <peilin.ye@bytedance.com> Signed-off-by: David S. Miller <davem@davemloft.net> 
As suggested by Cong, introduce a tracepoint for all ->sk_data_ready()
callback implementations.  For example:

<...>
  iperf-609  [002] .....  70.660425: sk_data_ready: family=2 protocol=6 func=sock_def_readable
  iperf-609  [002] .....  70.660436: sk_data_ready: family=2 protocol=6 func=sock_def_readable
<...>

Suggested-by: Cong Wang <cong.wang@bytedance.com>
Signed-off-by: Peilin Ye <peilin.ye@bytedance.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
soc: qcom: qmi: use const for struct qmi_elem_info 2022-08-29T22:33:01+00:00 Jeff Johnson quic_jjohnson@quicinc.com 2022-08-22T15:34:35+00:00 ff6d365898d4d31bd557954c7fc53f38977b491c Currently all usage of struct qmi_elem_info, which is used to define the QMI message encoding/decoding rules, does not use const. This prevents clients from registering const arrays. Since these arrays are always pre-defined, they should be const, so add the const qualifier to all places in the QMI interface where struct qmi_elem_info is used. Once this patch is in place, clients can independently update their pre-defined arrays to be const, as demonstrated in the QMI sample code. Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220822153435.7856-1-quic_jjohnson@quicinc.com 
Currently all usage of struct qmi_elem_info, which is used to define
the QMI message encoding/decoding rules, does not use const. This
prevents clients from registering const arrays. Since these arrays are
always pre-defined, they should be const, so add the const qualifier
to all places in the QMI interface where struct qmi_elem_info is used.

Once this patch is in place, clients can independently update their
pre-defined arrays to be const, as demonstrated in the QMI sample
code.

Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220822153435.7856-1-quic_jjohnson@quicinc.com
soc: qcom: qmi: Fix a typo in a comment 2021-11-18T20:21:56+00:00 Jason Wang wangborong@cdjrlc.com 2021-11-13T05:53:58+00:00 bd9ccaec6ac998196baa11380ad4651a7df62ef0 The double word `client' in a comment is repeated, thus one of them should be removed. Signed-off-by: Jason Wang <wangborong@cdjrlc.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211113055358.206533-1-wangborong@cdjrlc.com 
The double word `client' in a comment is repeated, thus one of
them should be removed.

Signed-off-by: Jason Wang <wangborong@cdjrlc.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20211113055358.206533-1-wangborong@cdjrlc.com
soc: qcom: qmi: Return EPROBE_DEFER if no address family 2019-12-11T06:44:34+00:00 Jeffrey Hugo jeffrey.l.hugo@gmail.com 2019-11-06T23:05:11+00:00 52af26e33e700158e6549f1465fcf9da099fabfa If a client comes up early in the boot process (perhaps was a built-in driver), qmi_handle_init() will likely fail with a EAFNOSUPPORT since the underlying ipc router hasn't init'd and registered the address family. This should not be a fatal error since chances are, the router will come up later, so recode the error to EPROBE_DEFER so that clients will retry later. Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Link: https://lore.kernel.org/r/20191106230511.1290-1-jeffrey.l.hugo@gmail.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> 
If a client comes up early in the boot process (perhaps was a built-in
driver), qmi_handle_init() will likely fail with a EAFNOSUPPORT since the
underlying ipc router hasn't init'd and registered the address family.
This should not be a fatal error since chances are, the router will come
up later, so recode the error to EPROBE_DEFER so that clients will retry
later.

Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Link: https://lore.kernel.org/r/20191106230511.1290-1-jeffrey.l.hugo@gmail.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
soc: qcom: qmi: Change txn wait to non-interruptible 2019-03-28T04:32:26+00:00 Chris Lew clew@codeaurora.org 2019-02-22T02:33:39+00:00 9324df5817c01f55fcde24da0da9df2c2f9392ac Current QMI clients are not userspace facing, if their threads are signaled, they do not do any signal checking or propagate the ERESTARTSYS return code up. Remove the interruptible option so clients can finish their QMI transactions even if the thread is signaled. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Chris Lew <clew@codeaurora.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org> 
Current QMI clients are not userspace facing, if their threads are
signaled, they do not do any signal checking or propagate the
ERESTARTSYS return code up. Remove the interruptible option so clients
can finish their QMI transactions even if the thread is signaled.

Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Chris Lew <clew@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Andy Gross <andy.gross@linaro.org>
soc: qcom: qmi_interface: Limit txn ids to U16_MAX 2018-11-14T18:02:07+00:00 Arun Kumar Neelakantam aneela@codeaurora.org 2018-10-03T05:40:02+00:00 c4fe17e0e3a346cc855b7b41c00ff7b04c56d32b Txn IDs created up to INT_MAX cause overflow while storing the IDs in u16 type supported by QMI header. Limit the txn IDs max value to U16_MAX to avoid overflow. Signed-off-by: Arun Kumar Neelakantam <aneela@codeaurora.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org> 
Txn IDs created up to INT_MAX cause overflow while storing
the IDs in u16 type supported by QMI header.

Limit the txn IDs max value to U16_MAX to avoid overflow.

Signed-off-by: Arun Kumar Neelakantam <aneela@codeaurora.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Andy Gross <andy.gross@linaro.org>