On Thu, 14 May 2020 at 16:29, Sudeep Holla <[email protected]> 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 <[email protected]> > > --- > > 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
