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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAPDyKFr7g5sEP06_cUO6zFk1GA_QmXg30aKdqrYA3RmU=ybTzA@mail.gmail.com>
Date: Fri, 28 Feb 2025 13:59:06 +0100
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Heiko Stübner <heiko@...ech.de>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>, Stephen Rothwell <sfr@...b.auug.org.au>, 
	"Martin K. Petersen" <martin.petersen@...cle.com>, Shawn Lin <shawn.lin@...k-chips.com>, 
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, 
	Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: build failure after merge of the pmdomain tree

On Fri, 28 Feb 2025 at 10:01, Heiko Stübner <heiko@...ech.de> wrote:
>
> Am Donnerstag, 27. Februar 2025, 18:05:18 MEZ schrieb Geert Uytterhoeven:
> > On Thu, 27 Feb 2025 at 17:16, Heiko Stübner <heiko@...ech.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@...aro.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.

I think the select better belongs in the soc specific Kconfig.

Like in arch/arm/mach-rockchip/Kconfig, for example.

>
> (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

This could make sense, but to me this is an orthogonal problem.

In the end, we really need the "select" to be done so the platform
becomes configured correctly.

Kind regards
Uffe