Re: arm_smccc_smc as generic smc interface?

From: Tony Lindgren <tony@atomide.com>
To: Jens Wiklander <jens.wiklander@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Sumit Garg <sumit.garg@linaro.org>, Arnd Bergmann <arnd@arndb.de>,
	Volodymyr Babchuk <vlad.babchuk@gmail.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	"Andrew F. Davis" <afd@ti.com>, Olof Johansson <olof@lixom.net>,
	Russell King <rmk+kernel@armlinux.org.uk>,
	Marc Zyngier <maz@kernel.org>, Andy Gross <andy.gross@linaro.org>,
	Colin Ian King <colin.king@canonical.com>,
	Will Deacon <will@kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: arm_smccc_smc as generic smc interface?
Date: Tue, 10 Dec 2019 07:38:40 -0800	[thread overview]
Message-ID: <20191210153840.GL35479@atomide.com> (raw)
In-Reply-To: <CAHUa44EJAjL+MGqgKd6YvQAg0z4hRYXb9MeTqsTYhAe-RBZt+g@mail.gmail.com>

* Jens Wiklander <jens.wiklander@linaro.org> [191210 08:10]:
> Hi Tony,
> 
> On Mon, Dec 9, 2019 at 7:07 PM Tony Lindgren <tony@atomide.com> wrote:
> >
> > Hi all,
> >
> > So it seems that we could make arm_smccc_smc() into a generic kernel
> > smc interface instead of being limited to optee usage. That is
> > assuming optee and legacy calls are never be enabled the same time
> > on a booted system :)
> 
> arm_smccc_smc() is not limited to OP-TEE only. A quick grep gives
> quite a few places of which OP-TEE is just one.

OK good to hear.

> > I know arm_smccc_smc() currently assumes a specific register usage
> > for the optee case, but AFAIK those limitations do not exist for
> > non-optee cases.
> 
> arm_smccc_smc() is for SMCs following SMC calling convention, see
> http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html

Hmm yes that's the part I'm wondering about. For older TI SoCs,
in the non-optee cases, the TI smc calls do not follow the newer
convention at least for r12 usage. For optee cases, TI SoCs follow
the convention AFAIK.

But assuming optee and non-optee are never active the same time,
handling the TI r12 quirk for non-optee cases should not cause
issues that I can think of.

However, if we wanted to have arm_smccc_smc() bail out for non-optee
cases for example, then it probably makes sense to move most of the
arm_smccc_smc() into a more generic function like arm_smc(), and
then have arm_smccc_smc() call arm_smc(). But AFAIK this should
not be needed as the optee code would not be active in the
non-optee case at all.

> > Does anybody see some other issues with making arm_smccc_smc() into
> > a generic smc call interface?
> 
> I suppose that depends on what you mean with a generic smc call
> interface. arm_smccc_smc() is quite generic already as I see it. :-)

Yes it already has nice quirk handling and should work nicely
to replace most of the SoC specific smc calls eventually :)

> > If there are some more optee specific considerations with making
> > arm_smccc_smc() into a generic interface, we could just set up
> > something generic that also arm_smccc_smc() can then call.
> 
> OP-TEE is relying on SMC calling convention
> http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html

Yes and the earlier non-optee smc cases may or may not follow it.

> > The use case I'm familiar with are the old TI smc calls that need
> > register specific quirks enabled only for the non-optee case,
> > while with optee enabled, quirks are not needed. There are
> > probably similar issues with other SoCs too.
> 
> I'm not too familiar with those. There's a few of them in the OP-TEE
> code base too, so at least some of them can be handled via the SMC
> calling convention.
> 
> In <arm-smccc.h> there's already been made room for some Qualcomm
> quirks, perhaps it's possible to use or extend it to cover the TI
> cases you have in mind.

Yeah that's my thinking too as long as there are no issues using
arm_smccc_smc() for non-optee cases.

Regards,

Tony

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