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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMuHMdU_Jb1YbwTQc+fkbRMw0O1+qR0KepG4U+ug1ED-+vferQ@mail.gmail.com>
Date: Fri, 28 Feb 2025 10:41:52 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Heiko Stübner <heiko@...ech.de>
Cc: Ulf Hansson <ulf.hansson@...aro.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

Hi Heiko,

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

Or protect the callsite in rockchip_do_pmu_set_power_domain() by
#ifdef CONFIG_ARM_PSCI?

Note that arch/arm/mm/proc-v7-bugs.c seems to call
arm_smccc_1_1_get_conduit() unconditionally, but the code is optimized
away due to spectre_v2_get_cpu_fw_mitigation_state() having a dummy
for the !CONFIG_ARM_PSCI case...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds