From: Alex Elder <elder@ieee.org> To: Jeff Johnson <quic_jjohnson@quicinc.com>, Alex Elder <elder@kernel.org>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Mathieu Poirier <mathieu.poirier@linaro.org>, Srinivas Kandagatla <srinivas.kandagatla@linaro.org>, Kalle Valo <kvalo@kernel.org>, Andy Gross <agross@kernel.org>, Bjorn Andersson <bjorn.andersson@linaro.org>, Konrad Dybcio <konrad.dybcio@somainline.org> Cc: linux-arm-msm@vger.kernel.org, netdev@vger.kernel.org, linux-remoteproc@vger.kernel.org, alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/4] Make QMI message rules const Date: Tue, 13 Sep 2022 15:21:30 -0500 [thread overview] Message-ID: <ac428312-745c-490e-dfb4-2208913c27c1@ieee.org> (raw) In-Reply-To: <5b0543dc-4db8-aa33-d469-0e185c82b221@quicinc.com> On 9/13/22 1:51 PM, Jeff Johnson wrote: > On 9/13/2022 6:58 AM, Alex Elder wrote: >> On 9/12/22 6:25 PM, Jeff Johnson wrote: >>> Change ff6d365898d ("soc: qcom: qmi: use const for struct >>> qmi_elem_info") allows QMI message encoding/decoding rules to be >>> const. So now update the definitions in the various client to take >>> advantage of this. Patches for ath10k and ath11k were perviously sent >>> separately. >> >> I have had this on my "to-do list" for ages. >> The commit you mention updates the code to be >> explicit about not modifying this data, which >> is great. >> >> I scanned over the changes, and I assume that >> all you did was make every object having the >> qmi_elem_info structure type be defined as >> constant. >> >> Why aren't you changing the "ei_array" field in >> the qmi_elem_info structure to be const? Or the >> "ei" field of the qmi_msg_handler structure? And >> the qmi_response_type_v01_ei array (and so on)? >> >> I like what you're doing, but can you comment >> on what your plans are beyond this series? >> Do you intend to make the rest of these fields >> const? > > Hi Alex, > My primary focus is the ath* wireless drivers, and my primary goal was > to make the tables there const. So this series, along with the two > out-of-series patches for ath10k and ath11k complete that scope of work. > > The lack of the other changes to the QMI data structures is simply due > to me not looking in depth at the QMI code beyond the registration > interface. > > I'll be happy to revisit this as a separate cleanup. Sounds good to me. Like I said I've wanted to do this myself, and as long as you've gotten this far I'd like to see it taken to completion. Compile-testing is most likely sufficient to make sure you got it right. I cherry-picked the one commit, and downloaded the series and found no new build warnings. Checkpatch would prefer you used "ff6d365898d4" rather than "ff6d365898d" for the commit ID, but that's OK. Anyway, for the whole series: Reviewed-by: Alex Elder <elder@linaro.org> > /jeff >
WARNING: multiple messages have this Message-ID (diff)
From: Alex Elder <elder@ieee.org> To: Jeff Johnson <quic_jjohnson@quicinc.com>, Alex Elder <elder@kernel.org>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Mathieu Poirier <mathieu.poirier@linaro.org>, Srinivas Kandagatla <srinivas.kandagatla@linaro.org>, Kalle Valo <kvalo@kernel.org>, Andy Gross <agross@kernel.org>, Bjorn Andersson <bjorn.andersson@linaro.org>, Konrad Dybcio <konrad.dybcio@somainline.org> Cc: linux-arm-msm@vger.kernel.org, alsa-devel@alsa-project.org, linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH 0/4] Make QMI message rules const Date: Tue, 13 Sep 2022 15:21:30 -0500 [thread overview] Message-ID: <ac428312-745c-490e-dfb4-2208913c27c1@ieee.org> (raw) In-Reply-To: <5b0543dc-4db8-aa33-d469-0e185c82b221@quicinc.com> On 9/13/22 1:51 PM, Jeff Johnson wrote: > On 9/13/2022 6:58 AM, Alex Elder wrote: >> On 9/12/22 6:25 PM, Jeff Johnson wrote: >>> Change ff6d365898d ("soc: qcom: qmi: use const for struct >>> qmi_elem_info") allows QMI message encoding/decoding rules to be >>> const. So now update the definitions in the various client to take >>> advantage of this. Patches for ath10k and ath11k were perviously sent >>> separately. >> >> I have had this on my "to-do list" for ages. >> The commit you mention updates the code to be >> explicit about not modifying this data, which >> is great. >> >> I scanned over the changes, and I assume that >> all you did was make every object having the >> qmi_elem_info structure type be defined as >> constant. >> >> Why aren't you changing the "ei_array" field in >> the qmi_elem_info structure to be const? Or the >> "ei" field of the qmi_msg_handler structure? And >> the qmi_response_type_v01_ei array (and so on)? >> >> I like what you're doing, but can you comment >> on what your plans are beyond this series? >> Do you intend to make the rest of these fields >> const? > > Hi Alex, > My primary focus is the ath* wireless drivers, and my primary goal was > to make the tables there const. So this series, along with the two > out-of-series patches for ath10k and ath11k complete that scope of work. > > The lack of the other changes to the QMI data structures is simply due > to me not looking in depth at the QMI code beyond the registration > interface. > > I'll be happy to revisit this as a separate cleanup. Sounds good to me. Like I said I've wanted to do this myself, and as long as you've gotten this far I'd like to see it taken to completion. Compile-testing is most likely sufficient to make sure you got it right. I cherry-picked the one commit, and downloaded the series and found no new build warnings. Checkpatch would prefer you used "ff6d365898d4" rather than "ff6d365898d" for the commit ID, but that's OK. Anyway, for the whole series: Reviewed-by: Alex Elder <elder@linaro.org> > /jeff >
next prev parent reply other threads:[~2022-09-13 20:21 UTC|newest] Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-09-12 23:25 [PATCH 0/4] Make QMI message rules const Jeff Johnson 2022-09-12 23:25 ` Jeff Johnson 2022-09-12 23:25 ` [PATCH 1/4] net: ipa: " Jeff Johnson 2022-09-12 23:25 ` Jeff Johnson 2022-09-12 23:25 ` [PATCH 2/4] remoteproc: sysmon: " Jeff Johnson 2022-09-12 23:25 ` Jeff Johnson 2022-09-12 23:25 ` [PATCH 3/4] slimbus: qcom-ngd-ctrl: " Jeff Johnson 2022-09-12 23:25 ` Jeff Johnson 2022-09-12 23:25 ` [PATCH 4/4] soc: qcom: pdr: " Jeff Johnson 2022-09-12 23:25 ` Jeff Johnson 2022-09-14 10:18 ` Sibi Sankar 2022-09-14 10:18 ` Sibi Sankar 2022-09-14 10:26 ` [PATCH 3/4] slimbus: qcom-ngd-ctrl: " Sibi Sankar 2022-09-14 10:26 ` Sibi Sankar 2022-09-16 13:06 ` Srinivas Kandagatla 2022-09-16 13:06 ` Srinivas Kandagatla 2022-09-16 15:20 ` Jeff Johnson 2022-09-16 15:20 ` Jeff Johnson 2022-09-14 10:24 ` [PATCH 2/4] remoteproc: sysmon: " Sibi Sankar 2022-09-14 10:24 ` Sibi Sankar 2022-09-14 10:22 ` [PATCH 1/4] net: ipa: " Sibi Sankar 2022-09-14 10:22 ` Sibi Sankar 2022-09-13 13:58 ` [PATCH 0/4] " Alex Elder 2022-09-13 13:58 ` Alex Elder 2022-09-13 18:51 ` Jeff Johnson 2022-09-13 18:51 ` Jeff Johnson 2022-09-13 20:21 ` Alex Elder [this message] 2022-09-13 20:21 ` Alex Elder 2022-09-13 22:19 ` Jeff Johnson 2022-09-13 22:19 ` Jeff Johnson 2022-09-15 18:47 ` Jeff Johnson 2022-09-15 18:47 ` Jeff Johnson 2022-09-14 23:47 ` [PATCH v2 " Jeff Johnson 2022-09-14 23:47 ` Jeff Johnson 2022-09-14 23:47 ` [PATCH v2 1/4] net: ipa: " Jeff Johnson 2022-09-14 23:47 ` Jeff Johnson 2022-10-18 21:17 ` [RESEND PATCH net-next] " Jeff Johnson 2022-10-21 12:20 ` patchwork-bot+netdevbpf 2022-09-14 23:47 ` [PATCH v2 2/4] remoteproc: sysmon: " Jeff Johnson 2022-09-14 23:47 ` Jeff Johnson 2022-10-18 20:44 ` [RESEND PATCH] " Jeff Johnson 2022-09-14 23:47 ` [PATCH v2 3/4] slimbus: qcom-ngd-ctrl: " Jeff Johnson 2022-09-14 23:47 ` Jeff Johnson 2022-10-18 22:25 ` [RESEND PATCH] " Jeff Johnson 2022-10-18 22:25 ` Jeff Johnson 2022-09-14 23:47 ` [PATCH v2 4/4] soc: qcom: pdr: " Jeff Johnson 2022-09-14 23:47 ` Jeff Johnson 2022-10-05 20:54 ` [RESEND] " Jeff Johnson 2022-10-18 3:14 ` [PATCH v2 0/4] " Bjorn Andersson 2022-10-18 3:14 ` Bjorn Andersson 2022-12-07 15:53 ` Bjorn Andersson 2022-12-07 15:53 ` Bjorn Andersson
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=ac428312-745c-490e-dfb4-2208913c27c1@ieee.org \ --to=elder@ieee.org \ --cc=agross@kernel.org \ --cc=alsa-devel@alsa-project.org \ --cc=bjorn.andersson@linaro.org \ --cc=davem@davemloft.net \ --cc=edumazet@google.com \ --cc=elder@kernel.org \ --cc=konrad.dybcio@somainline.org \ --cc=kuba@kernel.org \ --cc=kvalo@kernel.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-remoteproc@vger.kernel.org \ --cc=mathieu.poirier@linaro.org \ --cc=netdev@vger.kernel.org \ --cc=pabeni@redhat.com \ --cc=quic_jjohnson@quicinc.com \ --cc=srinivas.kandagatla@linaro.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.