On Thu, May 14, 2020 at 05:06:22PM +0200, Etienne Carriere wrote: > 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.
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
