| Message ID | 20200514082428.27864-1-etienne.carriere@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | firmware: arm_scmi: fix SMCCC_RET_NOT_SUPPORTED management | expand |
On Thu, May 14, 2020 at 10:24:28AM +0200, Etienne Carriere wrote: > Fix management of argument a0 output value of arm_smccc_1_1_invoke() that > should consider only SMCCC_RET_NOT_SUPPORTED as reporting an unsupported > function ID as correctly stated in the inline comment. > I agree on the comment part, but ... > Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> > --- > drivers/firmware/arm_scmi/smc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/firmware/arm_scmi/smc.c b/drivers/firmware/arm_scmi/smc.c > index 49bc4b0e8428..637ad439545f 100644 > --- a/drivers/firmware/arm_scmi/smc.c > +++ b/drivers/firmware/arm_scmi/smc.c > @@ -115,7 +115,7 @@ static int smc_send_message(struct scmi_chan_info *cinfo, > mutex_unlock(&scmi_info->shmem_lock); > > /* Only SMCCC_RET_NOT_SUPPORTED is valid error code */ > - if (res.a0) > + if (res.a0 == SMCCC_RET_NOT_SUPPORTED) > return -EOPNOTSUPP; Now this will return 0 for all values other than SMCCC_RET_NOT_SUPPORTED. Is that what we need ? Or do you see non-zero res.a0 for a success case ? If later, we need some fixing, otherwise it is safer to leave it as is IMO.
On Thu, 14 May 2020 at 16:29, Sudeep Holla <sudeep.holla@arm.com> wrote: > > On Thu, May 14, 2020 at 10:24:28AM +0200, Etienne Carriere wrote: > > Fix management of argument a0 output value of arm_smccc_1_1_invoke() that > > should consider only SMCCC_RET_NOT_SUPPORTED as reporting an unsupported > > function ID as correctly stated in the inline comment. > > > > I agree on the comment part, but ... > > > Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> > > --- > > drivers/firmware/arm_scmi/smc.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/firmware/arm_scmi/smc.c b/drivers/firmware/arm_scmi/smc.c > > index 49bc4b0e8428..637ad439545f 100644 > > --- a/drivers/firmware/arm_scmi/smc.c > > +++ b/drivers/firmware/arm_scmi/smc.c > > @@ -115,7 +115,7 @@ static int smc_send_message(struct scmi_chan_info *cinfo, > > mutex_unlock(&scmi_info->shmem_lock); > > > > /* Only SMCCC_RET_NOT_SUPPORTED is valid error code */ > > - if (res.a0) > > + if (res.a0 == SMCCC_RET_NOT_SUPPORTED) > > return -EOPNOTSUPP; > > Now this will return 0 for all values other than SMCCC_RET_NOT_SUPPORTED. > Is that what we need ? Or do you see non-zero res.a0 for a success case ? > If later, we need some fixing, otherwise it is safer to leave it as is > IMO. Firmware following SMCCC v1.x for some OEM/SiP invocation may simply not modify invocation register argument a0 on invocation with a SCMI-SMC transport function ID. Resulting in res.a0 == scmi_info->func_id here. Which is, by SMCCC v1.x not an error. From SMCCC v1.x only SMCCC_RET_NOT_SUPPORTED (-1 signed extended is a reserved ) is a generic return error whatever function ID value. Or consider part of the SCMI-SMC transport API that output arg a0 shall be 0 on success, SMCCC_RET_NOT_SUPPORTED if function ID is not supported and any non-zero value for non-generic **error** codes. etienne > > -- > Regards, > Sudeep
On Thu, May 14, 2020 at 05:06:22PM +0200, Etienne Carriere wrote: > On Thu, 14 May 2020 at 16:29, Sudeep Holla <sudeep.holla@arm.com> wrote: > > > > On Thu, May 14, 2020 at 10:24:28AM +0200, Etienne Carriere wrote: > > > Fix management of argument a0 output value of arm_smccc_1_1_invoke() that > > > should consider only SMCCC_RET_NOT_SUPPORTED as reporting an unsupported > > > function ID as correctly stated in the inline comment. > > > > > > > I agree on the comment part, but ... > > > > > Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> > > > --- > > > drivers/firmware/arm_scmi/smc.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/firmware/arm_scmi/smc.c b/drivers/firmware/arm_scmi/smc.c > > > index 49bc4b0e8428..637ad439545f 100644 > > > --- a/drivers/firmware/arm_scmi/smc.c > > > +++ b/drivers/firmware/arm_scmi/smc.c > > > @@ -115,7 +115,7 @@ static int smc_send_message(struct scmi_chan_info *cinfo, > > > mutex_unlock(&scmi_info->shmem_lock); > > > > > > /* Only SMCCC_RET_NOT_SUPPORTED is valid error code */ > > > - if (res.a0) > > > + if (res.a0 == SMCCC_RET_NOT_SUPPORTED) > > > return -EOPNOTSUPP; > > > > Now this will return 0 for all values other than SMCCC_RET_NOT_SUPPORTED. > > Is that what we need ? Or do you see non-zero res.a0 for a success case ? > > If later, we need some fixing, otherwise it is safer to leave it as is > > IMO. > > Firmware following SMCCC v1.x for some OEM/SiP invocation may simply > not modify invocation register argument a0 on invocation with a > SCMI-SMC transport function ID. Yikes, I need to check specification again for this. I will also check with the firmware implementation team/ > Resulting in res.a0 == scmi_info->func_id here. Which is, by SMCCC > v1.x not an error. > But that may get fatal the result in some other cases, not here for sure. But I would rather flag that as error so that it is fixed. Anyways I will check on this again/ > From SMCCC v1.x only SMCCC_RET_NOT_SUPPORTED (-1 signed extended is a > reserved ) is a generic return error whatever function ID value. > Not really, there are couple more I think now. But yes I need to check on the generic return part. > Or consider part of the SCMI-SMC transport API that output arg a0 > shall be 0 on success, SMCCC_RET_NOT_SUPPORTED if function ID is not > supported and any non-zero value for non-generic **error** codes. > I prefer that. Anyways I will check and if anything changes I will ping back on this thread. -- Regards, Sudeep
> > Or consider part of the SCMI-SMC transport API that output arg a0 > > shall be 0 on success, SMCCC_RET_NOT_SUPPORTED if function ID is not > > supported and any non-zero value for non-generic **error** codes. > > > > I prefer that. Anyways I will check and if anything changes I will ping > back on this thread. I don't have a strong opinion on whether considering or not 0 as success, for whatever the function ID used here for SCMI message notification. We can assume at least 0 is default returned in a0 when the function ID is used in SCMI SMC transport. Thanks for the feedback. > -- > Regards, > Sudeep
diff --git a/drivers/firmware/arm_scmi/smc.c b/drivers/firmware/arm_scmi/smc.c index 49bc4b0e8428..637ad439545f 100644 --- a/drivers/firmware/arm_scmi/smc.c +++ b/drivers/firmware/arm_scmi/smc.c @@ -115,7 +115,7 @@ static int smc_send_message(struct scmi_chan_info *cinfo, mutex_unlock(&scmi_info->shmem_lock); /* Only SMCCC_RET_NOT_SUPPORTED is valid error code */ - if (res.a0) + if (res.a0 == SMCCC_RET_NOT_SUPPORTED) return -EOPNOTSUPP; return 0; }
Fix management of argument a0 output value of arm_smccc_1_1_invoke() that should consider only SMCCC_RET_NOT_SUPPORTED as reporting an unsupported function ID as correctly stated in the inline comment. Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> --- drivers/firmware/arm_scmi/smc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)