Re: linux-next: build failure after merge of the pmdomain tree

["Heiko Stübner" <heiko@sntech.de>]

Am Donnerstag, 27. Februar 2025, 18:05:18 MEZ schrieb Geert Uytterhoeven:
> On Thu, 27 Feb 2025 at 17:16, Heiko Stübner <heiko@sntech.de> wrote:
> > Am Donnerstag, 27. Februar 2025, 16:56:01 MEZ schrieb Geert Uytterhoeven:
> > > On Mon, 24 Feb 2025 at 13:27, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > > So this was fixed by adding a dependency on HAVE_ARM_SMCCC_DISCOVERY[1].
> > >
> > > I am no Rockchip expert, but is this the correct fix?
> > > As arch/arm/boot/dts/rockchip/rk3036.dtsi uses enable-method =
> > > "rockchip,rk3036-smp", e.g. RK3036 does not depend on PSCI, so I assume
> > > you could run a kernel without PSCI support on RK3036 before?
> >
> > All still relevant 32bit Rockchip SoCs (rv11*) already switched over to
> > PSCI. So if one uses some sort of distro-kernel (or one simply built from
> > the in-kernel defconfig), PSCI support will be in there already.
> 
> OK.
> 
> > So the only case where this is relevant, is for kernels custom-build for
> > one specific soc type.
> >
> > The rk3036 (and rk3128) are from the same era as the rk3288 - 2014 .
> > That's more than 10 years ago. And we're not talking about these old
> > boards not working anymore - just a _possible_ size increase in very
> > special cases (of not using any distro-like kernel).
> >
> > arm32 psci.o is 176kb ... and even my r3036-kylin board came with 512MB
> > ram. So personally I'm not too worried.
> 
> My worry is not so much about the size increase, but about
> CONFIG_ROCKCHIP_PM_DOMAINS becoming disabled when
> running "make oldconfig" if CONFIG_PSCI is disabled.

ah, now I get it :-)


I guess there are ways to prevent this (still uncommon) case:

(1) The CONFIG_ARM_GIC_V3 already uses a
  select HAVE_ARM_SMCCC_DISCOVERY
The pm-domain could do that as well.

(2) The main __arm_smccc_smc has a stub for the !CONFIG_HAVE_ARM_SMCCC
case, and arm_smccc_1_1_get_conduit() is described as 
    "When SMCCCv1.1 is not present, returns SMCCC_CONDUIT_NONE."

------
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index 67f6fdf2e7cd..3e6b34570a64 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -300,7 +300,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()
----

I guess case (1) might be the easier one, because stubbing out only one
smccc function might raise the issue of what about the others.