[PATCH 1/2] firmware: smccc: Stub out get_conduit()

[PATCH 1/2] firmware: smccc: Stub out get_conduit()

[Robin Murphy]

Various callers use arm_smccc_1_1_get_conduit() to guard their
arm_smccc_smc() calls - since the latter is already stubbed out to
support optional usage in !HAVE_ARM_SMCCC configs, do the equivalent
for the former as well to make life easier.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
 include/linux/arm-smccc.h | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index a3863da1510e..97dc4d47c664 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -315,7 +315,14 @@ enum arm_smccc_conduit {
  *
  * When SMCCCv1.1 is not present, returns SMCCC_CONDUIT_NONE.
  */
+#ifdef CONFIG_HAVE_ARM_SMCCC_DISCOVERY
 enum arm_smccc_conduit arm_smccc_1_1_get_conduit(void);
+#else
+static inline enum arm_smccc_conduit arm_smccc_1_1_get_conduit(void)
+{
+	return SMCCC_CONDUIT_NONE;
+}
+#endif
 
 /**
  * arm_smccc_get_version()
-- 
2.39.2.101.g768bb238c484.dirty

[PATCH 2/2] pmdomain: rockchip: Relax SMCCC dependency

[Robin Murphy]

Most 32-bit Rockchip platforms do not use PSCI, so having to select
ARM_PSCI to satisfy a dependency chain to retain working power domain
support is a bit weird and non-obvious. Now that the offending SMCCC API
is properly stubbed out for optional usage, we can relax this again.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
 drivers/pmdomain/rockchip/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/pmdomain/rockchip/Kconfig b/drivers/pmdomain/rockchip/Kconfig
index 218d43186e5b..ffe5e7b78494 100644
--- a/drivers/pmdomain/rockchip/Kconfig
+++ b/drivers/pmdomain/rockchip/Kconfig
@@ -4,7 +4,6 @@ if ARCH_ROCKCHIP || COMPILE_TEST
 config ROCKCHIP_PM_DOMAINS
 	bool "Rockchip generic power domain"
 	depends on PM
-	depends on HAVE_ARM_SMCCC_DISCOVERY
 	depends on REGULATOR
 	select PM_GENERIC_DOMAINS
 	help
-- 
2.39.2.101.g768bb238c484.dirty

Re: [PATCH 1/2] firmware: smccc: Stub out get_conduit()

[Heiko Stuebner]

Am Dienstag, 20. Mai 2025, 19:10:16 Mitteleuropäische Sommerzeit schrieb Robin Murphy:
> Various callers use arm_smccc_1_1_get_conduit() to guard their
> arm_smccc_smc() calls - since the latter is already stubbed out to
> support optional usage in !HAVE_ARM_SMCCC configs, do the equivalent
> for the former as well to make life easier.
> 
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>

Reviewed-by: Heiko Stuebner <heiko@sntech.de>

Way nicer than to require arm32 rockchip platforms to
enable smcc stuff, even if not in use.

> ---
>  include/linux/arm-smccc.h | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
> index a3863da1510e..97dc4d47c664 100644
> --- a/include/linux/arm-smccc.h
> +++ b/include/linux/arm-smccc.h
> @@ -315,7 +315,14 @@ enum arm_smccc_conduit {
>   *
>   * When SMCCCv1.1 is not present, returns SMCCC_CONDUIT_NONE.
>   */
> +#ifdef CONFIG_HAVE_ARM_SMCCC_DISCOVERY
>  enum arm_smccc_conduit arm_smccc_1_1_get_conduit(void);
> +#else
> +static inline enum arm_smccc_conduit arm_smccc_1_1_get_conduit(void)
> +{
> +	return SMCCC_CONDUIT_NONE;
> +}
> +#endif
>  
>  /**
>   * arm_smccc_get_version()
> 

Re: [PATCH 2/2] pmdomain: rockchip: Relax SMCCC dependency

[Heiko Stuebner]

Am Dienstag, 20. Mai 2025, 19:10:17 Mitteleuropäische Sommerzeit schrieb Robin Murphy:
> Most 32-bit Rockchip platforms do not use PSCI, so having to select
> ARM_PSCI to satisfy a dependency chain to retain working power domain
> support is a bit weird and non-obvious. Now that the offending SMCCC API
> is properly stubbed out for optional usage, we can relax this again.
> 
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>


Reviewed-by: Heiko Stuebner <heiko@sntech.de>

Of course this needs patch1 of this series to get applied
first.

I think for bisectability, doing this directly in patch1 might
be less dangerous though?


Heiko

> ---
>  drivers/pmdomain/rockchip/Kconfig | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/pmdomain/rockchip/Kconfig b/drivers/pmdomain/rockchip/Kconfig
> index 218d43186e5b..ffe5e7b78494 100644
> --- a/drivers/pmdomain/rockchip/Kconfig
> +++ b/drivers/pmdomain/rockchip/Kconfig
> @@ -4,7 +4,6 @@ if ARCH_ROCKCHIP || COMPILE_TEST
>  config ROCKCHIP_PM_DOMAINS
>  	bool "Rockchip generic power domain"
>  	depends on PM
> -	depends on HAVE_ARM_SMCCC_DISCOVERY
>  	depends on REGULATOR
>  	select PM_GENERIC_DOMAINS
>  	help
> 

Re: [PATCH 2/2] pmdomain: rockchip: Relax SMCCC dependency

[Urja]

Hi,

Applied these, disabled PSCI, built it, ran it, the system works, so:

This patchset is
Tested-by: Urja Rannikko <urja@urja.dev>

Re: [PATCH 1/2] firmware: smccc: Stub out get_conduit()

[Ulf Hansson]

On Tue, 20 May 2025 at 19:10, Robin Murphy <robin.murphy@arm.com> wrote:
>
> Various callers use arm_smccc_1_1_get_conduit() to guard their
> arm_smccc_smc() calls - since the latter is already stubbed out to
> support optional usage in !HAVE_ARM_SMCCC configs, do the equivalent
> for the former as well to make life easier.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>

Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>

Kind regards
Uffe

> ---
>  include/linux/arm-smccc.h | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
> index a3863da1510e..97dc4d47c664 100644
> --- a/include/linux/arm-smccc.h
> +++ b/include/linux/arm-smccc.h
> @@ -315,7 +315,14 @@ enum arm_smccc_conduit {
>   *
>   * When SMCCCv1.1 is not present, returns SMCCC_CONDUIT_NONE.
>   */
> +#ifdef CONFIG_HAVE_ARM_SMCCC_DISCOVERY
>  enum arm_smccc_conduit arm_smccc_1_1_get_conduit(void);
> +#else
> +static inline enum arm_smccc_conduit arm_smccc_1_1_get_conduit(void)
> +{
> +       return SMCCC_CONDUIT_NONE;
> +}
> +#endif
>
>  /**
>   * arm_smccc_get_version()
> --
> 2.39.2.101.g768bb238c484.dirty
>
>

Re: [PATCH 2/2] pmdomain: rockchip: Relax SMCCC dependency

[Ulf Hansson]

On Tue, 20 May 2025 at 20:38, Heiko Stuebner <heiko@sntech.de> wrote:
>
> Am Dienstag, 20. Mai 2025, 19:10:17 Mitteleuropäische Sommerzeit schrieb Robin Murphy:
> > Most 32-bit Rockchip platforms do not use PSCI, so having to select
> > ARM_PSCI to satisfy a dependency chain to retain working power domain
> > support is a bit weird and non-obvious. Now that the offending SMCCC API
> > is properly stubbed out for optional usage, we can relax this again.
> >
> > Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>
>
> Reviewed-by: Heiko Stuebner <heiko@sntech.de>
>
> Of course this needs patch1 of this series to get applied
> first.
>
> I think for bisectability, doing this directly in patch1 might
> be less dangerous though?
>

If it helps, I can pick both patches via my pmdomain tree, to make
sure patch1 really gets applied prior to patch2.

Mark, Sudeep, Lorenzo do you see any problems with this?

[...]

Kind regards
Uffe

Re: [PATCH 2/2] pmdomain: rockchip: Relax SMCCC dependency

[Robin Murphy]

On 2025-05-21 12:41 pm, Ulf Hansson wrote:
> On Tue, 20 May 2025 at 20:38, Heiko Stuebner <heiko@sntech.de> wrote:
>>
>> Am Dienstag, 20. Mai 2025, 19:10:17 Mitteleuropäische Sommerzeit schrieb Robin Murphy:
>>> Most 32-bit Rockchip platforms do not use PSCI, so having to select
>>> ARM_PSCI to satisfy a dependency chain to retain working power domain
>>> support is a bit weird and non-obvious. Now that the offending SMCCC API
>>> is properly stubbed out for optional usage, we can relax this again.
>>>
>>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>>
>>
>> Reviewed-by: Heiko Stuebner <heiko@sntech.de>
>>
>> Of course this needs patch1 of this series to get applied
>> first.
>>
>> I think for bisectability, doing this directly in patch1 might
>> be less dangerous though?
>>
> 
> If it helps, I can pick both patches via my pmdomain tree, to make
> sure patch1 really gets applied prior to patch2.

Perhaps I should have been less lazy and written a brief cover letter, 
but indeed, given the dependency my hope was for these to both go 
together through the same tree - it's just an open question of which 
tree that should be :)

Cheers,
Robin.

> Mark, Sudeep, Lorenzo do you see any problems with this?
> 
> [...]
> 
> Kind regards
> Uffe