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

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

On Mon, 20 Apr 2020 at 17:35, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> 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 ?

Ok.
Sure you can add my Reviewed-by as well as my Tested-by, assuming I
tested this change over the right version.
I used your branch for-next/scmi, from commit a2fe6324.

Regards,
Etienne

>
> --
> Regards,
> Sudeep

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