The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Julian Braha <julianbraha@gmail.com>, Thomas Gleixner <tglx@kernel.org>
Cc: florian.fainelli@broadcom.com, rjui@broadcom.com,
	sbranden@broadcom.com, linux@armlinux.org.uk, Frank.Li@nxp.com,
	s.hauer@pengutronix.de, bcm-kernel-feedback-list@broadcom.com,
	radu@rendec.net, kernel@pengutronix.de, festevam@gmail.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, imx@lists.linux.dev, arnd@arndb.de,
	Sudeep Holla <sudeep.holla@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>
Subject: Re: [PATCH] irqchip: gic-v3: fix unmet dependency on ARM_PSCI_FW
Date: Thu, 20 Aug 2026 09:22:15 +0100	[thread overview]
Message-ID: <877bllp5fs.wl-maz@kernel.org> (raw)
In-Reply-To: <87lda2j5gs.ffs@fw13>

On Wed, 19 Aug 2026 20:05:55 +0100,
Thomas Gleixner <tglx@kernel.org> wrote:
> 
> On Sat, Aug 01 2026 at 22:22, Julian Braha wrote:
> 
> > ARM_GIC_V3 selects HAVE_ARM_SMCCC_DISCOVERY without ensuring its
> > dependency, ARM_PSCI_FW is met. However, ARM_PSCI_FW should be
> > selected by the system type, so ARM_GIC_V3 should depend on ARM_PSCI_FW.
> >
> > Additionally, the systems that select ARM_GIC_V3 (ARCH_BRCMSTB and
> > SOC_IMX8M) need to select its dependency, ARM_PSCI_FW, too.
> >
> > This unmet dependency was found by kconfirm, a static analysis tool for
> > Kconfig.
> 
> Marc?
> 

[+ SMCCC folks]

Thanks for roping me in.

This looks like the wrong fix altogether. Whatever the Broadcom stuff
depends on is irrelevant, and has nothing to do with GICv3. Same thing
for the NXP contraptions.

If there is something to do *for the GIC driver*, it is to make sure
it compiles/links correctly when the platform does not select options
that are not required. Why would NXP and Broadcom care about an
erratum that is specific to NVIDIA?

I also disagree with what the commit message asserts, ARM_PSCI_FW is
selected *globally* on arm64, not on a per platform basis (TFFT!).
The NVIDIA machine being an arm64 platform, the correct dependency fix
is to select HAVE_ARM_SMCCC_DISCOVERY on arm64.

The overall issue is that there is no fallback to do something
sensible when HAVE_ARM_SMCCC_DISCOVERY is not selected. Random drivers
should not have to guess or add random #ifdefs all over the shop.

I came up with the following hack, which compiles correctly on 32bit
ARM without PSCI at all. YMMV.

Thanks,

	M.

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 42f2278a702d0..937f17ec93a2e 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -37,7 +37,7 @@ config ARM_GIC_V3
 	bool
 	select IRQ_DOMAIN_HIERARCHY
 	select GENERIC_IRQ_EFFECTIVE_AFF_MASK if SMP
-	select HAVE_ARM_SMCCC_DISCOVERY
+	select HAVE_ARM_SMCCC_DISCOVERY if ARM64
 	select IRQ_MSI_IOMMU
 
 config ARM_GIC_ITS_PARENT
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index 4de81848fe2ee..75f9d3f1723b5 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -324,6 +324,7 @@ enum arm_smccc_conduit {
 	SMCCC_CONDUIT_HVC,
 };
 
+#ifdef CONFIG_HAVE_ARM_SMCCC_DISCOVERY
 /**
  * arm_smccc_1_1_get_conduit()
  *
@@ -363,6 +364,12 @@ s32 arm_smccc_get_soc_id_version(void);
  * When ARM_SMCCC_ARCH_SOC_ID is not present, returns SMCCC_RET_NOT_SUPPORTED.
  */
 s32 arm_smccc_get_soc_id_revision(void);
+#else   /* CONFIG_HAVE_ARM_SMCCC_DISCOVERY */
+#define arm_smccc_1_1_get_conduit()	SMCCC_CONDUIT_NONE
+#define arm_smccc_get_version()		0
+#define arm_smccc_get_soc_id_version()	SMCCC_RET_NOT_SUPPORTED
+#define arm_smccc_get_soc_id_revision()	SMCCC_RET_NOT_SUPPORTED
+#endif	/* CONFIG_HAVE_ARM_SMCCC_DISCOVERY */
 
 #ifndef __ASSEMBLY__
 

-- 
Jazz isn't dead. It just smells funny.

      reply	other threads:[~2026-08-20  8:19 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-01 21:22 [PATCH] irqchip: gic-v3: fix unmet dependency on ARM_PSCI_FW Julian Braha
2026-08-19 19:05 ` Thomas Gleixner
2026-08-20  8:22   ` Marc Zyngier [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877bllp5fs.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=Frank.Li@nxp.com \
    --cc=arnd@arndb.de \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=festevam@gmail.com \
    --cc=florian.fainelli@broadcom.com \
    --cc=imx@lists.linux.dev \
    --cc=julianbraha@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=lpieralisi@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=radu@rendec.net \
    --cc=rjui@broadcom.com \
    --cc=s.hauer@pengutronix.de \
    --cc=sbranden@broadcom.com \
    --cc=sudeep.holla@kernel.org \
    --cc=tglx@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox