Re: [PATCH v4 4/4] firmware: arm_scmi: Add qcom hvc/shmem transport support
From: Sudeep Holla <hidden>
Date: 2023-10-06 07:28:28
Also in:
linux-arm-msm, linux-devicetree, lkml
On Thu, Oct 05, 2023 at 03:20:16PM -0700, Bjorn Andersson wrote:
On Wed, Oct 04, 2023 at 05:06:30PM +0100, Sudeep Holla wrote:quoted
On Tue, Oct 03, 2023 at 09:16:27AM -0700, Nikunj Kela wrote:quoted
On 10/3/2023 4:19 AM, Sudeep Holla wrote:quoted
On Mon, Sep 11, 2023 at 12:43:59PM -0700, Nikunj Kela wrote:quoted
diff --git a/drivers/firmware/arm_scmi/smc.c b/drivers/firmware/arm_scmi/smc.c[..]quoted
quoted
quoted
quoted
@@ -63,6 +66,8 @@ struct scmi_smc { u32 func_id; u32 param_page; u32 param_offset; + u64 cap_id;Can it be unsigned long instead so that it just works for both 32 and 64 bit.My first version of this patch was ulong but Bjorn suggested to make this structure size fixed i.e. architecture independent. Hence changed it to u64. If you are ok with ulong, I can change it back to ulong.SMCCC pre-v1.2 used the common structure in that way. I don't see any issue with that. I haven't followed Bjorn suggestions/comments though.My request was that funcId and capId is an ABI between the firmware and the OS, so I'd like for that to use well defined, fixed sized, data types - if nothing else just for documentation purpose. These values will be truncated when passed to arm_smccc_1_1_invoke() anyways, so I don't have any opinion against using unsigned long here... PS. I understand why func_id is u32, but why are param_page and param_offset u32?
Good point. Sorry I somehow missed your original comment, my bad. Yes, it is good to be consistent. Sorry if I added any confusion by missing o read your comment and understanding it before I responded. -- Regards, Sudeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel