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

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 526 bytes --]

Hi all,

After merging the pmdomain tree, today's linux-next build (x86_64
allmodconfig) failed like this:

x86_64-linux-gnu-ld: vmlinux.o: in function `rockchip_do_pmu_set_power_domain':
pm-domains.c:(.text+0x19aa103): undefined reference to `arm_smccc_1_1_get_conduit'

Caused by commit

  61eeb9678789 ("pmdomain: rockchip: Check if SMC could be handled by TA")

$ grep CONFIG_HAVE_ARM_SMCCC_DISCOVERY .config
$

I have used the pmdomain tree from next-20250219 for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Shawn Lin]

在 2025/2/20 8:33, Stephen Rothwell 写道:
> Hi all,
> 
> After merging the pmdomain tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> x86_64-linux-gnu-ld: vmlinux.o: in function `rockchip_do_pmu_set_power_domain':
> pm-domains.c:(.text+0x19aa103): undefined reference to `arm_smccc_1_1_get_conduit'
> 
> Caused by commit
> 
>    61eeb9678789 ("pmdomain: rockchip: Check if SMC could be handled by TA")
> 
> $ grep CONFIG_HAVE_ARM_SMCCC_DISCOVERY .config

It seems x86_64_defconfig did't enable  CONFIG_HAVE_ARM_SMCCC_DISCOVERY 
which apparently belongs to ARM stuff.

Selecting HAVE_ARM_SMCCC_DISCOVERY and ARM_PSCI_FW should pass the
x86_64 allmodconfig compile.

--- a/drivers/pmdomain/rockchip/Kconfig
+++ b/drivers/pmdomain/rockchip/Kconfig
@@ -5,6 +5,8 @@ config ROCKCHIP_PM_DOMAINS
         bool "Rockchip generic power domain"
         depends on PM
         select PM_GENERIC_DOMAINS
+       select ARM_PSCI_FW
+       select HAVE_ARM_SMCCC_DISCOVERY
         help
           Say y here to enable power domain support.
           In order to meet high performance and low power requirements, 
a power


> $
> 
> I have used the pmdomain tree from next-20250219 for today.
> 

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 681 bytes --]

Hi all,

On Thu, 20 Feb 2025 11:33:38 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the pmdomain tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> x86_64-linux-gnu-ld: vmlinux.o: in function `rockchip_do_pmu_set_power_domain':
> pm-domains.c:(.text+0x19aa103): undefined reference to `arm_smccc_1_1_get_conduit'
> 
> Caused by commit
> 
>   61eeb9678789 ("pmdomain: rockchip: Check if SMC could be handled by TA")
> 
> $ grep CONFIG_HAVE_ARM_SMCCC_DISCOVERY .config
> $
> 
> I have used the pmdomain tree from next-20250219 for today.

I am still seeing this build failure.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1002 bytes --]

Hi all,

On Mon, 24 Feb 2025 12:23:18 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Thu, 20 Feb 2025 11:33:38 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the pmdomain tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > x86_64-linux-gnu-ld: vmlinux.o: in function `rockchip_do_pmu_set_power_domain':
> > pm-domains.c:(.text+0x19aa103): undefined reference to `arm_smccc_1_1_get_conduit'
> > 
> > Caused by commit
> > 
> >   61eeb9678789 ("pmdomain: rockchip: Check if SMC could be handled by TA")
> > 
> > $ grep CONFIG_HAVE_ARM_SMCCC_DISCOVERY .config
> > $
> > 
> > I have used the pmdomain tree from next-20250219 for today.  
> 
> I am still seeing this build failure.

And now that commit from the pmdomain tree has been merged into the
scsi-mkp tree and so the build failure happens there as well.

I have used the scsi-mkp tree from next-20250221 for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Ulf Hansson]

On Mon, 24 Feb 2025 at 06:20, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> On Mon, 24 Feb 2025 12:23:18 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Thu, 20 Feb 2025 11:33:38 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > After merging the pmdomain tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > >
> > > x86_64-linux-gnu-ld: vmlinux.o: in function `rockchip_do_pmu_set_power_domain':
> > > pm-domains.c:(.text+0x19aa103): undefined reference to `arm_smccc_1_1_get_conduit'
> > >
> > > Caused by commit
> > >
> > >   61eeb9678789 ("pmdomain: rockchip: Check if SMC could be handled by TA")
> > >
> > > $ grep CONFIG_HAVE_ARM_SMCCC_DISCOVERY .config
> > > $
> > >
> > > I have used the pmdomain tree from next-20250219 for today.
> >
> > I am still seeing this build failure.
>
> And now that commit from the pmdomain tree has been merged into the
> scsi-mkp tree and so the build failure happens there as well.
>
> I have used the scsi-mkp tree from next-20250221 for today.
>
> --
> Cheers,
> Stephen Rothwell

Stephen, thanks for reporting and sorry for the delay.

I have now fixed the problem on the next branch as well on the
immutable rockchip branch. Martin, please pull again.

Sorry for the mess!

Shawn-Lin, no need for any action from your side, I have taken care of
the issue.

Kind regards
Uffe

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

[Martin K. Petersen]

> I have now fixed the problem on the next branch as well on the
> immutable rockchip branch. Martin, please pull again.

OK. I have updated my scsi-staging.

-- 
Martin K. Petersen	Oracle Linux Engineering

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

[Geert Uytterhoeven]

Hi Ulf,

On Mon, 24 Feb 2025 at 13:27, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On Mon, 24 Feb 2025 at 06:20, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > On Mon, 24 Feb 2025 12:23:18 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > On Thu, 20 Feb 2025 11:33:38 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > After merging the pmdomain tree, today's linux-next build (x86_64
> > > > allmodconfig) failed like this:
> > > >
> > > > x86_64-linux-gnu-ld: vmlinux.o: in function `rockchip_do_pmu_set_power_domain':
> > > > pm-domains.c:(.text+0x19aa103): undefined reference to `arm_smccc_1_1_get_conduit'
> > > >
> > > > Caused by commit
> > > >
> > > >   61eeb9678789 ("pmdomain: rockchip: Check if SMC could be handled by TA")
> > > >
> > > > $ grep CONFIG_HAVE_ARM_SMCCC_DISCOVERY .config
> > > > $
> > > >
> > > > I have used the pmdomain tree from next-20250219 for today.
> > >
> > > I am still seeing this build failure.
> >
> > And now that commit from the pmdomain tree has been merged into the
> > scsi-mkp tree and so the build failure happens there as well.
> >
> > I have used the scsi-mkp tree from next-20250221 for today.
> >
> > --
> > Cheers,
> > Stephen Rothwell
>
> Stephen, thanks for reporting and sorry for the delay.
>
> I have now fixed the problem on the next branch as well on the
> immutable rockchip branch. Martin, please pull again.

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?

[1] https://web.git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm.git/commit/?h=next&id=bc4bc2a1609712e6c5de01be8a20341b710dc99b

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-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

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

[Heiko Stübner]

Hi Geert,

Am Donnerstag, 27. Februar 2025, 16:56:01 MEZ schrieb Geert Uytterhoeven:
> Hi Ulf,
> 
> On Mon, 24 Feb 2025 at 13:27, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > On Mon, 24 Feb 2025 at 06:20, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > On Mon, 24 Feb 2025 12:23:18 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > On Thu, 20 Feb 2025 11:33:38 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > > After merging the pmdomain tree, today's linux-next build (x86_64
> > > > > allmodconfig) failed like this:
> > > > >
> > > > > x86_64-linux-gnu-ld: vmlinux.o: in function `rockchip_do_pmu_set_power_domain':
> > > > > pm-domains.c:(.text+0x19aa103): undefined reference to `arm_smccc_1_1_get_conduit'
> > > > >
> > > > > Caused by commit
> > > > >
> > > > >   61eeb9678789 ("pmdomain: rockchip: Check if SMC could be handled by TA")
> > > > >
> > > > > $ grep CONFIG_HAVE_ARM_SMCCC_DISCOVERY .config
> > > > > $
> > > > >
> > > > > I have used the pmdomain tree from next-20250219 for today.
> > > >
> > > > I am still seeing this build failure.
> > >
> > > And now that commit from the pmdomain tree has been merged into the
> > > scsi-mkp tree and so the build failure happens there as well.
> > >
> > > I have used the scsi-mkp tree from next-20250221 for today.
> > >
> > > --
> > > Cheers,
> > > Stephen Rothwell
> >
> > Stephen, thanks for reporting and sorry for the delay.
> >
> > I have now fixed the problem on the next branch as well on the
> > immutable rockchip branch. Martin, please pull again.
> 
> 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.


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.


Heiko

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

[Geert Uytterhoeven]

Hi Heiko,

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:
> > > On Mon, 24 Feb 2025 at 06:20, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > On Mon, 24 Feb 2025 12:23:18 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > > On Thu, 20 Feb 2025 11:33:38 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > > > After merging the pmdomain tree, today's linux-next build (x86_64
> > > > > > allmodconfig) failed like this:
> > > > > >
> > > > > > x86_64-linux-gnu-ld: vmlinux.o: in function `rockchip_do_pmu_set_power_domain':
> > > > > > pm-domains.c:(.text+0x19aa103): undefined reference to `arm_smccc_1_1_get_conduit'
> > > > > >
> > > > > > Caused by commit
> > > > > >
> > > > > >   61eeb9678789 ("pmdomain: rockchip: Check if SMC could be handled by TA")
> > > > > >
> > > > > > $ grep CONFIG_HAVE_ARM_SMCCC_DISCOVERY .config
> > > > > > $
> > > > > >
> > > > > > I have used the pmdomain tree from next-20250219 for today.
> > > > >
> > > > > I am still seeing this build failure.
> > > >
> > > > And now that commit from the pmdomain tree has been merged into the
> > > > scsi-mkp tree and so the build failure happens there as well.
> > > >
> > > > I have used the scsi-mkp tree from next-20250221 for today.
> > > >
> > > > --
> > > > Cheers,
> > > > Stephen Rothwell
> > >
> > > Stephen, thanks for reporting and sorry for the delay.
> > >
> > > I have now fixed the problem on the next branch as well on the
> > > immutable rockchip branch. Martin, please pull again.
> >
> > 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.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-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

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

[Heiko Stübner]

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.

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

[Geert Uytterhoeven]

Hi Heiko,

On Fri, 28 Feb 2025 at 10:01, Heiko Stübner <heiko@sntech.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@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.

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@linux-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

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

[Ulf Hansson]

On Fri, 28 Feb 2025 at 10:01, Heiko Stübner <heiko@sntech.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@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.

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

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 5337 bytes --]

Hi all,

After merging the pmdomain tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

drivers/pmdomain/mediatek/mtk-pm-domains.c: In function 'scpsys_sec_infra_power_on':
drivers/pmdomain/mediatek/mtk-pm-domains.c:128:30: error: storage size of 'res' isn't known
  128 |         struct arm_smccc_res res;
      |                              ^~~
drivers/pmdomain/mediatek/mtk-pm-domains.c:131:9: error: implicit declaration of function 'arm_smccc_smc' [-Wimplicit-function-declaration]
  131 |         arm_smccc_smc(MTK_SIP_KERNEL_HWCCF_CONTROL, cmd, 0, 0, 0, 0, 0, 0, &res);
      |         ^~~~~~~~~~~~~
In file included from drivers/pmdomain/mediatek/mtk-pm-domains.c:18:
include/linux/soc/mediatek/mtk_sip_svc.h:22:9: error: implicit declaration of function 'ARM_SMCCC_CALL_VAL' [-Wimplicit-function-declaration]
   22 |         ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, MTK_SIP_SMC_CONVENTION, \
      |         ^~~~~~~~~~~~~~~~~~
drivers/pmdomain/mediatek/mtk-pm-domains.c:56:41: note: in expansion of macro 'MTK_SIP_SMC_CMD'
   56 | #define MTK_SIP_KERNEL_HWCCF_CONTROL    MTK_SIP_SMC_CMD(0x540)
      |                                         ^~~~~~~~~~~~~~~
drivers/pmdomain/mediatek/mtk-pm-domains.c:131:23: note: in expansion of macro 'MTK_SIP_KERNEL_HWCCF_CONTROL'
  131 |         arm_smccc_smc(MTK_SIP_KERNEL_HWCCF_CONTROL, cmd, 0, 0, 0, 0, 0, 0, &res);
      |                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/soc/mediatek/mtk_sip_svc.h:22:28: error: 'ARM_SMCCC_FAST_CALL' undeclared (first use in this function)
   22 |         ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, MTK_SIP_SMC_CONVENTION, \
      |                            ^~~~~~~~~~~~~~~~~~~
drivers/pmdomain/mediatek/mtk-pm-domains.c:56:41: note: in expansion of macro 'MTK_SIP_SMC_CMD'
   56 | #define MTK_SIP_KERNEL_HWCCF_CONTROL    MTK_SIP_SMC_CMD(0x540)
      |                                         ^~~~~~~~~~~~~~~
drivers/pmdomain/mediatek/mtk-pm-domains.c:131:23: note: in expansion of macro 'MTK_SIP_KERNEL_HWCCF_CONTROL'
  131 |         arm_smccc_smc(MTK_SIP_KERNEL_HWCCF_CONTROL, cmd, 0, 0, 0, 0, 0, 0, &res);
      |                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/soc/mediatek/mtk_sip_svc.h:22:28: note: each undeclared identifier is reported only once for each function it appears in
   22 |         ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, MTK_SIP_SMC_CONVENTION, \
      |                            ^~~~~~~~~~~~~~~~~~~
drivers/pmdomain/mediatek/mtk-pm-domains.c:56:41: note: in expansion of macro 'MTK_SIP_SMC_CMD'
   56 | #define MTK_SIP_KERNEL_HWCCF_CONTROL    MTK_SIP_SMC_CMD(0x540)
      |                                         ^~~~~~~~~~~~~~~
drivers/pmdomain/mediatek/mtk-pm-domains.c:131:23: note: in expansion of macro 'MTK_SIP_KERNEL_HWCCF_CONTROL'
  131 |         arm_smccc_smc(MTK_SIP_KERNEL_HWCCF_CONTROL, cmd, 0, 0, 0, 0, 0, 0, &res);
      |                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/soc/mediatek/mtk_sip_svc.h:18:41: error: 'ARM_SMCCC_SMC_32' undeclared (first use in this function)
   18 | #define MTK_SIP_SMC_CONVENTION          ARM_SMCCC_SMC_32
      |                                         ^~~~~~~~~~~~~~~~
include/linux/soc/mediatek/mtk_sip_svc.h:22:49: note: in expansion of macro 'MTK_SIP_SMC_CONVENTION'
   22 |         ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, MTK_SIP_SMC_CONVENTION, \
      |                                                 ^~~~~~~~~~~~~~~~~~~~~~
drivers/pmdomain/mediatek/mtk-pm-domains.c:56:41: note: in expansion of macro 'MTK_SIP_SMC_CMD'
   56 | #define MTK_SIP_KERNEL_HWCCF_CONTROL    MTK_SIP_SMC_CMD(0x540)
      |                                         ^~~~~~~~~~~~~~~
drivers/pmdomain/mediatek/mtk-pm-domains.c:131:23: note: in expansion of macro 'MTK_SIP_KERNEL_HWCCF_CONTROL'
  131 |         arm_smccc_smc(MTK_SIP_KERNEL_HWCCF_CONTROL, cmd, 0, 0, 0, 0, 0, 0, &res);
      |                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/soc/mediatek/mtk_sip_svc.h:23:28: error: 'ARM_SMCCC_OWNER_SIP' undeclared (first use in this function)
   23 |                            ARM_SMCCC_OWNER_SIP, fn_id)
      |                            ^~~~~~~~~~~~~~~~~~~
drivers/pmdomain/mediatek/mtk-pm-domains.c:56:41: note: in expansion of macro 'MTK_SIP_SMC_CMD'
   56 | #define MTK_SIP_KERNEL_HWCCF_CONTROL    MTK_SIP_SMC_CMD(0x540)
      |                                         ^~~~~~~~~~~~~~~
drivers/pmdomain/mediatek/mtk-pm-domains.c:131:23: note: in expansion of macro 'MTK_SIP_KERNEL_HWCCF_CONTROL'
  131 |         arm_smccc_smc(MTK_SIP_KERNEL_HWCCF_CONTROL, cmd, 0, 0, 0, 0, 0, 0, &res);
      |                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/pmdomain/mediatek/mtk-pm-domains.c:128:30: warning: unused variable 'res' [-Wunused-variable]
  128 |         struct arm_smccc_res res;
      |                              ^~~
drivers/pmdomain/mediatek/mtk-pm-domains.c:133:1: error: control reaches end of non-void function [-Werror=return-type]
  133 | }
      | ^
cc1: some warnings being treated as errors

Caused by commit

  df4e9ec1ed86 ("pmdomain: mediatek: Add support for secure HWCCF infra power on")

(and maybe others)

I have used the pmdomain tree from next-20251022 for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]