Re: [PATCH] firmware: arm_scmi: Fix return error code in smc_send_message

From: Sudeep Holla <sudeep.holla@arm.com>
To: Etienne Carriere <etienne.carriere@linaro.org>
Cc: Peng Fan <peng.fan@nxp.com>,
	linux-arm-kernel@lists.infradead.org,
	Sudeep Holla <sudeep.holla@arm.com>
Subject: Re: [PATCH] firmware: arm_scmi: Fix return error code in smc_send_message
Date: Mon, 20 Apr 2020 16:35:46 +0100	[thread overview]
Message-ID: <20200420145712.GA307@bogus> (raw)
In-Reply-To: <CAN5uoS8vGCABXvscR160=Dy_iZytinB2y+E2wbp6_KyQMFW5Tg@mail.gmail.com>

On Sun, Apr 19, 2020 at 12:04:27PM +0200, Etienne Carriere wrote:
> Hello Sudeep,
> 
> On Fri, 17 Apr 2020 at 12:32, Sudeep Holla <sudeep.holla@arm.com> wrote:
> >
> > SMCCC can return one of the 2 return error code here: NOT_SUPPORTED(-1)
> > and INVALID_PARAMETER(-3). Map them to appropriate Linux error codes
> > namely -EOPNOTSUPP and -EINVAL respectively. -EINVAL is also returned
> > for any other return values.
> 
> Reading back the SMCCC spec, I see that INVALID_PARAMETER(-3) and
> SUCCESS(0) are Arm Architecture Calls specific return values.
> The only generic return value that applies to any SMCCC call is
> NOT_SUPPORTED(-1).
>
> As for an SCMI SMCCC transport layer, any other value than -1 means
> the call is supported and one should rely on the statuses provided in
> the shared memory buffer related to the function ID.
>

Yes I agree, I had the change to reflect above initially and for some reason
I decided to extend.

> >
> > Cc: Peng Fan <peng.fan@nxp.com>
> > Reported-by: Etienne Carriere <etienne.carriere@linaro.org>
> > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> > ---
> >  drivers/firmware/arm_scmi/smc.c | 6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/firmware/arm_scmi/smc.c b/drivers/firmware/arm_scmi/smc.c
> > index 833e793b5391..a8b5ecb8927a 100644
> > --- a/drivers/firmware/arm_scmi/smc.c
> > +++ b/drivers/firmware/arm_scmi/smc.c
> > @@ -114,7 +114,11 @@ static int smc_send_message(struct scmi_chan_info *cinfo,
> >
> >         mutex_unlock(&scmi_info->shmem_lock);
> >
> > -       return res.a0;
> > +       if (res.a0 == SMCCC_RET_NOT_SUPPORTED)
> > +               return -EOPNOTSUPP;
> > +       else if (res.a0)
> > +               return -EINVAL;
> 
> Related to my comment above:
> I have no strong opinion on that as I guess SCMI SMCCC transport layer
> in secure world firmware could ensure output argument a0 is set not 0.
> That said, I might be nitpicking but I still think th 2 lines could be removed.
> 
> Is there any strong reason for testing finer return status from res.a0?
>

No, I will drop. With that can I have you Ack/Reviewed-by ?

-- 
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel