linux-kernel - Re: [PATCH] firmware: arm_scmi: fix i.MX build dependency

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: <Zzm_X0o-TkkGQeAN@pluto>
Date: Sun, 17 Nov 2024 10:03:11 +0000
From: Cristian Marussi <cristian.marussi@....com>
To: Arnd Bergmann <arnd@...nel.org>
Cc: Sudeep Holla <sudeep.holla@....com>, Shawn Guo <shawnguo@...nel.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Mark Brown <broonie@...nel.org>, Arnd Bergmann <arnd@...db.de>,
	Cristian Marussi <cristian.marussi@....com>,
	Pengutronix Kernel Team <kernel@...gutronix.de>,
	Fabio Estevam <festevam@...il.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
	Peng Fan <peng.fan@....com>, arm-scmi@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, imx@...ts.linux.dev,
	linux-kernel@...r.kernel.org, linux-sound@...r.kernel.org
Subject: Re: [PATCH] firmware: arm_scmi: fix i.MX build dependency

On Sat, Nov 16, 2024 at 12:05:18AM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@...db.de>
> 

Hi Arnd,

> The newly added SCMI vendor driver references functions in the
> protocol driver but needs a Kconfig dependency to ensure it can link,
> essentially the Kconfig dependency needs to be reversed to match the
> link time dependency:
> 
> arm-linux-gnueabi-ld: sound/soc/fsl/fsl_mqs.o: in function `fsl_mqs_sm_write':
> fsl_mqs.c:(.text+0x1aa): undefined reference to `scmi_imx_misc_ctrl_set'
> arm-linux-gnueabi-ld: sound/soc/fsl/fsl_mqs.o: in function `fsl_mqs_sm_read':
> fsl_mqs.c:(.text+0x1ee): undefined reference to `scmi_imx_misc_ctrl_get'
> 

The SCMI drivers, like the newly added IMX_SCMI_MISC_DRV, generally make
ue of the related vendor protocol like IMX_SCMI_MISC_EXT, BUT the SCMI
stack is designed in a way that NO symbols are needed to be exported by
the protocol layer (to avoid a huge and growing number of symbols
exports)...so usually the current DRV-->PROTO dependency is fine.

In this case, AFAIU, it is the SCMI driver that in turn exports a few
helpers that are used by another driver fsl_mqs, which in turn could be
compiled and work with or without the SCMI stack, so with this patch we
are artificially reversing the DRV<--PROTO dependency to solve this
scenario in all the compillation scenarios...

....BUT given that the IMX_SCMI_MISC_DRV is the one that should export
the missing symbols could NOT this solved in a cleaner way, without
adding the fake reverse dependency, by instead modifying the header of
the driver with something like the classic:

--->8-----
diff --git a/include/linux/firmware/imx/sm.h b/include/linux/firmware/imx/sm.h
index 9b85a3f028d1..3a7a3ec367c5 100644
--- a/include/linux/firmware/imx/sm.h
+++ b/include/linux/firmware/imx/sm.h
@@ -17,7 +17,19 @@
 #define SCMI_IMX_CTRL_SAI4_MCLK                4       /* WAKE SAI4 MCLK */
 #define SCMI_IMX_CTRL_SAI5_MCLK                5       /* WAKE SAI5 MCLK */
 
+#ifdef IMX_SCMI_MISC_DRV
 int scmi_imx_misc_ctrl_get(u32 id, u32 *num, u32 *val);
 int scmi_imx_misc_ctrl_set(u32 id, u32 val);
+#else
+static inline int scmi_imx_misc_ctrl_get(u32 id, u32 *num, u32 *val)
+{
+       return 0;
+}
+
+static inline int scmi_imx_misc_ctrl_set(u32 id, u32 val)
+{
+       return 0;
+}
+#endif
 
 #endif
----->8-----------

....to just support compilation in all the scenarios.

> This however only works after changing the dependency in the SND_SOC_FSL_MQS
> driver as well, which uses 'select IMX_SCMI_MISC_DRV' to turn on a
> driver it depends on. This is generally a bad idea, so the best solution
> is to change that into a dependency.
> 
> To allow the ASoC driver to keep building with the SCMI support, this
> needs to be an optional dependency that enforces the link-time
> dependency if IMX_SCMI_MISC_DRV is a loadable module but not
> depend on it if that is disabled.
> 

...and maybe with the above additions you could avoid also these other
dep changes...

...not sure if I am missing something and I have definitely not tested
any of my babbling above...

Thanks,
Cristian