Allow a module that wants to make SMC calls to detect if it should be
using smc or hvc.
Signed-off-by: Ali Saidi <[email protected]>
---
arch/arm64/kernel/acpi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 803f0494dd3e..ea41c6541d3c 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -119,6 +119,7 @@ bool acpi_psci_use_hvc(void)
{
return acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC;
}
+EXPORT_SYMBOL_GPL(acpi_psci_use_hvc);
/*
* acpi_fadt_sanity_check() - Check FADT presence and carry out sanity
--
2.15.3.AMZN
On Tue, Jun 04, 2019 at 08:30:59PM +0000, Ali Saidi wrote:
> Allow a module that wants to make SMC calls to detect if it should be
> using smc or hvc.
>
> Signed-off-by: Ali Saidi <[email protected]>
> ---
> arch/arm64/kernel/acpi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index 803f0494dd3e..ea41c6541d3c 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -119,6 +119,7 @@ bool acpi_psci_use_hvc(void)
> {
> return acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC;
> }
> +EXPORT_SYMBOL_GPL(acpi_psci_use_hvc);
>
I would rather have this in drivers/firmware/psci/psci.c checking the
value of psci_ops.conduit so that it's not just ACPI specific and can
be used on DT platforms too if required.
--
Regards,
Sudeep
On Wed, Jun 05, 2019 at 10:40:31AM +0100, Sudeep Holla wrote:
> On Tue, Jun 04, 2019 at 08:30:59PM +0000, Ali Saidi wrote:
> > Allow a module that wants to make SMC calls to detect if it should be
> > using smc or hvc.
> >
> > Signed-off-by: Ali Saidi <[email protected]>
> > ---
> > arch/arm64/kernel/acpi.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> > index 803f0494dd3e..ea41c6541d3c 100644
> > --- a/arch/arm64/kernel/acpi.c
> > +++ b/arch/arm64/kernel/acpi.c
> > @@ -119,6 +119,7 @@ bool acpi_psci_use_hvc(void)
> > {
> > return acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC;
> > }
> > +EXPORT_SYMBOL_GPL(acpi_psci_use_hvc);
> >
>
> I would rather have this in drivers/firmware/psci/psci.c checking the
> value of psci_ops.conduit so that it's not just ACPI specific and can
> be used on DT platforms too if required.
I'd also like this to not hook into PSCI internals. This code cares
about SMCCC, not PSCI. We also really shouldn't need to spread the
conduit management everywhere, too. We should be abel to have probe code
do:
if (!is_smccc_1_1_available())
goto fail_probe;
... and runtime code do:
res = arm_smccc_1_1_call(...);
... which is much clearner.
I'd started cleaning that up [1], but I haven't had the chance to rebase
and repost it.
Ali, I assume your firmware has SMCCCv1.1+. Is that the case?
Thanks,
Mark.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=arm64/smccc-cleanup
On Wed, Jun 05, 2019 at 11:38:40AM +0100, Mark Rutland wrote:
> On Wed, Jun 05, 2019 at 10:40:31AM +0100, Sudeep Holla wrote:
> > On Tue, Jun 04, 2019 at 08:30:59PM +0000, Ali Saidi wrote:
> > > Allow a module that wants to make SMC calls to detect if it should be
> > > using smc or hvc.
> > >
> > > Signed-off-by: Ali Saidi <[email protected]>
> > > ---
> > > arch/arm64/kernel/acpi.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> > > index 803f0494dd3e..ea41c6541d3c 100644
> > > --- a/arch/arm64/kernel/acpi.c
> > > +++ b/arch/arm64/kernel/acpi.c
> > > @@ -119,6 +119,7 @@ bool acpi_psci_use_hvc(void)
> > > {
> > > return acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC;
> > > }
> > > +EXPORT_SYMBOL_GPL(acpi_psci_use_hvc);
> > >
> >
> > I would rather have this in drivers/firmware/psci/psci.c checking the
> > value of psci_ops.conduit so that it's not just ACPI specific and can
> > be used on DT platforms too if required.
>
> I'd also like this to not hook into PSCI internals. This code cares
> about SMCCC, not PSCI. We also really shouldn't need to spread the
> conduit management everywhere, too.
I agree. I remember suggesting the same to Xilinx a while ago but I
didn't see your patches in the mainline.
--
Regards,
Sudeep
On 6/5/19, 5:40 AM, "Mark Rutland" <[email protected]> wrote:
Ali, I assume your firmware has SMCCCv1.1+. Is that the case?
Yes, it does. I'm happy to be able to call a generic function instead of having to figure out which conduit to use.
Ali