#
9b09c0f2 |
|
22-Sep-2023 |
Unnathi Chalicheemala <quic_uchalich@quicinc.com> |
soc: qcom: Switch to EXPORT_SYMBOL_GPL() 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>
|
#
56310520 |
|
20-Apr-2023 |
Tejun Heo <tj@kernel.org> |
soc: qcom: qmi: Use alloc_ordered_workqueue() to create ordered workqueues 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
|
#
40e0b090 |
|
19-Jan-2023 |
Peilin Ye <peilin.ye@bytedance.com> |
net/sock: Introduce trace_sk_data_ready() 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>
|
#
ff6d3658 |
|
22-Aug-2022 |
Jeff Johnson <quic_jjohnson@quicinc.com> |
soc: qcom: qmi: use const for struct qmi_elem_info 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
|
#
bd9ccaec |
|
12-Nov-2021 |
Jason Wang <wangborong@cdjrlc.com> |
soc: qcom: qmi: Fix a typo in a comment 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
|
#
52af26e3 |
|
06-Nov-2019 |
Jeffrey Hugo <jeffrey.l.hugo@gmail.com> |
soc: qcom: qmi: Return EPROBE_DEFER if no address family 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>
|
#
9324df58 |
|
21-Feb-2019 |
Chris Lew <clew@codeaurora.org> |
soc: qcom: qmi: Change txn wait to non-interruptible 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>
|
#
c4fe17e0 |
|
02-Oct-2018 |
Arun Kumar Neelakantam <aneela@codeaurora.org> |
soc: qcom: qmi_interface: Limit txn ids to U16_MAX 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>
|
#
7df5ff25 |
|
27-Apr-2018 |
Alex Elder <elder@linaro.org> |
soc: qcom: qmi: fix a buffer sizing bug In qmi_handle_init(), a buffer is allocated for to hold messages received through the handle's socket. Any "normal" messages (expected by the caller) will have a header prepended, so the buffer size is adjusted to accomodate that. The buffer must also be of sufficient size to receive control messages, so the size is increased if necessary to ensure these will fit. Unfortunately the calculation is done wrong, making it possible for the calculated buffer size to be too small to hold a "normal" message. Specifically, if: recv_buf_size > sizeof(struct qrtr_ctrl_pkt) - sizeof(struct qmi_header) AND recv_buf_size < sizeof(struct qrtr_ctrl_pkt) the current logic will use sizeof(struct qrtr_ctrl_pkt) as the receive buffer size, which is not enough to hold the maximum "normal" message plus its header. Currently this problem occurs for (13 < recv_buf_size < 20). This patch corrects this. Signed-off-by: Alex Elder <elder@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
|
#
9b2c45d4 |
|
12-Feb-2018 |
Denys Vlasenko <dvlasenk@redhat.com> |
net: make getname() functions return length rather than use int* parameter Changes since v1: Added changes in these files: drivers/infiniband/hw/usnic/usnic_transport.c drivers/staging/lustre/lnet/lnet/lib-socket.c drivers/target/iscsi/iscsi_target_login.c drivers/vhost/net.c fs/dlm/lowcomms.c fs/ocfs2/cluster/tcp.c security/tomoyo/network.c Before: All these functions either return a negative error indicator, or store length of sockaddr into "int *socklen" parameter and return zero on success. "int *socklen" parameter is awkward. For example, if caller does not care, it still needs to provide on-stack storage for the value it does not need. None of the many FOO_getname() functions of various protocols ever used old value of *socklen. They always just overwrite it. This change drops this parameter, and makes all these functions, on success, return length of sockaddr. It's always >= 0 and can be differentiated from an error. Tests in callers are changed from "if (err)" to "if (err < 0)", where needed. rpc_sockname() lost "int buflen" parameter, since its only use was to be passed to kernel_getsockname() as &buflen and subsequently not used in any way. Userspace API is not changed. text data bss dec hex filename 30108430 2633624 873672 33615726 200ef6e vmlinux.before.o 30108109 2633612 873672 33615393 200ee21 vmlinux.o Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com> CC: David S. Miller <davem@davemloft.net> CC: linux-kernel@vger.kernel.org CC: netdev@vger.kernel.org CC: linux-bluetooth@vger.kernel.org CC: linux-decnet-user@lists.sourceforge.net CC: linux-wireless@vger.kernel.org CC: linux-rdma@vger.kernel.org CC: linux-sctp@vger.kernel.org CC: linux-nfs@vger.kernel.org CC: linux-x25@vger.kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
3830d077 |
|
05-Dec-2017 |
Bjorn Andersson <bjorn.andersson@linaro.org> |
soc: qcom: Introduce QMI helpers Drivers that needs to communicate with a remote QMI service all has to perform the operations of discovering the service, encoding and decoding the messages and operate the socket. This introduces an abstraction for these common operations, reducing most of the duplication in such cases. Acked-by: Chris Lew <clew@codeaurora.org> Tested-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
|