[PATCH v4 0/3] soc: qcom: ubwc: Fix link error

[PATCH v4 0/3] soc: qcom: ubwc: Fix link error

[Daniel Baluta]

Fix link error caused by the fact that drivers/soc/qcom/ubwc_config.c
enabled via QCOM_UBWC_CONFIG uses unconditionally symbols from
drivers/soc/qcom/smem.c enabled via CONFIG_QCOM_SMEM.

Changes since v3:
- fix issues pointed by sashiko https://sashiko.dev/#/patchset/20260812130421.670527-1-daniel.baluta%40nxp.com
 - add new patches 2/3 in order to fix unmet dependcy for VIDEO_QCOM_IRIS
 - Use IS_REACHABLE instead of IS_ENABLED to avoid the situation we use
   some symbols in builtin kernel but their definitions sits in a
module.

Remark for Dmitry, at this point I think v1 would have been a better
option.
Link to v1:
-	https://lore.kernel.org/imx/1521da8e-18df-4d7b-a255-5ca133bd5ccc@oss.nxp.com/T/#t



Daniel Baluta (3):
  soc: qcom: ubwc: Fix link error when QCOM_SMEM=n
  media: iris: Fix unmet dependency when QCOM_SMEM=n
  soc: qcom: ubwc: Use IS_REACHABLE() instead of IS_ENABLED()

 drivers/gpu/drm/msm/Kconfig              | 2 +-
 drivers/media/platform/qcom/iris/Kconfig | 2 +-
 drivers/soc/qcom/Kconfig                 | 1 +
 include/linux/soc/qcom/ubwc.h            | 2 +-
 4 files changed, 4 insertions(+), 3 deletions(-)

-- 
2.45.2

[PATCH v4 1/3] soc: qcom: ubwc: Fix link error when QCOM_SMEM=n

[Daniel Baluta]

DRM_MSM unconditionally selects QCOM_UBWC_CONFIG, which calls SMEM APIs,
causing a link error on non-Qcom platforms (e.g. SOC_IMX5):

  arm-linux-gnueabihf-ld: ubwc_config.c:(.text+0x2c): undefined
      reference to 'qcom_smem_is_available'
  arm-linux-gnueabihf-ld: ubwc_config.c:(.text+0x4c): undefined
      reference to 'qcom_smem_dram_get_hbb'

Make QCOM_UBWC_CONFIG depend on QCOM_SMEM to make the requirement
explicit, and guard the select in DRM_MSM with ARCH_QCOM && QCOM_SMEM so
it is only selected when its dependency is met.

Fixes: 1b445022d1d0 ("soc: qcom: ubwc: Get HBB from SMEM")
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
---
 drivers/gpu/drm/msm/Kconfig | 2 +-
 drivers/soc/qcom/Kconfig    | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 09469d56513b0..1670dbc9464c6 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -22,7 +22,7 @@ config DRM_MSM
 	select TMPFS
 	select QCOM_SCM
 	select QCOM_PAS
-	select QCOM_UBWC_CONFIG
+	select QCOM_UBWC_CONFIG if ARCH_QCOM && QCOM_SMEM
 	select WANT_DEV_COREDUMP
 	select SND_SOC_HDMI_CODEC if SND_SOC
 	select SYNC_FILE
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index fd4d4ecd2df0f..e0629e9328c87 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -321,6 +321,7 @@ config QCOM_QMI_HELPERS
 
 config QCOM_UBWC_CONFIG
 	tristate
+	depends on QCOM_SMEM
 	help
 	  Most Qualcomm SoCs feature a number of Universal Bandwidth Compression
 	  (UBWC) engines across various IP blocks, which need to be initialized
-- 
2.45.2

[PATCH v4 2/3] media: iris: Fix unmet dependency when QCOM_SMEM=n

[Daniel Baluta]

VIDEO_QCOM_IRIS unconditionally selects QCOM_UBWC_CONFIG, violating the
Kconfig rule that a selecting symbol must carry all dependencies of the
selected one.  QCOM_UBWC_CONFIG now depends on QCOM_SMEM, so with
COMPILE_TEST and QCOM_SMEM=n Kconfig forces QCOM_UBWC_CONFIG=y and the
build fails with an undefined reference to qcom_smem_is_available.

Guard the select the same way DRM_MSM already does.

Fixes: c43207553867 ("media: iris: retrieve UBWC platform configuration")
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
---
 drivers/media/platform/qcom/iris/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/qcom/iris/Kconfig b/drivers/media/platform/qcom/iris/Kconfig
index 388c9bbc81365..04a4440a2dd51 100644
--- a/drivers/media/platform/qcom/iris/Kconfig
+++ b/drivers/media/platform/qcom/iris/Kconfig
@@ -6,7 +6,7 @@ config VIDEO_QCOM_IRIS
 	select QCOM_MDT_LOADER
 	select QCOM_SCM
 	select QCOM_PAS
-	select QCOM_UBWC_CONFIG
+	select QCOM_UBWC_CONFIG if ARCH_QCOM && QCOM_SMEM
 	select VIDEOBUF2_DMA_CONTIG
 	help
 	  This is a V4L2 driver for Qualcomm iris video accelerator
-- 
2.45.2

[PATCH v4 3/3] soc: qcom: ubwc: Use IS_REACHABLE() instead of IS_ENABLED()

[Daniel Baluta]

When DRM_MSM=y and QCOM_SMEM=m, the conditional select evaluates to 'm'
so QCOM_UBWC_CONFIG=m.  IS_ENABLED() is true for both =y and =m, so the
real qcom_ubwc_config_get_data() declaration is exposed to built-in
callers, which cannot resolve it at vmlinux link time.

IS_REACHABLE() is false when the caller is built-in and the dependency is
only a module, causing the inline stub to be used instead.

Fixes: 1b445022d1d0 ("soc: qcom: ubwc: Get HBB from SMEM")
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
---
 include/linux/soc/qcom/ubwc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/soc/qcom/ubwc.h b/include/linux/soc/qcom/ubwc.h
index a7372d9c25fbc..1a61238f6d4d5 100644
--- a/include/linux/soc/qcom/ubwc.h
+++ b/include/linux/soc/qcom/ubwc.h
@@ -36,7 +36,7 @@ struct qcom_ubwc_cfg_data {
 #define UBWC_5_0 0x50000000
 #define UBWC_6_0 0x60000000
 
-#if IS_ENABLED(CONFIG_QCOM_UBWC_CONFIG)
+#if IS_REACHABLE(CONFIG_QCOM_UBWC_CONFIG)
 const struct qcom_ubwc_cfg_data *qcom_ubwc_config_get_data(void);
 #else
 static inline const struct qcom_ubwc_cfg_data *qcom_ubwc_config_get_data(void)
-- 
2.45.2

Re: [PATCH v4 3/3] soc: qcom: ubwc: Use IS_REACHABLE() instead of IS_ENABLED()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [High] Using IS_REACHABLE() masks a Kconfig dependency mismatch, causing guaranteed runtime probe failures for built-in drivers when the dependency is built as a module.

Pre-existing issues:
- [Medium] Missing resource cleanup in a5xx_gpu_init() when qcom_ubwc_config_get_data() fails.
--

--- Patch [3]: [PATCH v4 3/3] soc: qcom: ubwc: Use IS_REACHABLE() instead of IS_ENABLED() ---
commit 27da698f8aa42c85fe3250533a0ac637d13515f3
Author: Daniel Baluta <daniel.baluta@nxp.com>

soc: qcom: ubwc: Use IS_REACHABLE() instead of IS_ENABLED()

This commit changes the conditional check for QCOM_UBWC_CONFIG from
IS_ENABLED to IS_REACHABLE. This aims to resolve a link error when
built-in callers try to use the function while the dependency is built
as a module.

> diff --git a/include/linux/soc/qcom/ubwc.h b/include/linux/soc/qcom/ubwc.h
> index a7372d9c25fbc..1a61238f6d4d5 100644
> --- a/include/linux/soc/qcom/ubwc.h
> +++ b/include/linux/soc/qcom/ubwc.h
[ ... ]
> @@ -36,7 +36,7 @@ struct qcom_ubwc_cfg_data {
>  #define UBWC_5_0 0x50000000
>  #define UBWC_6_0 0x60000000
>  
> -#if IS_ENABLED(CONFIG_QCOM_UBWC_CONFIG)
> +#if IS_REACHABLE(CONFIG_QCOM_UBWC_CONFIG)

[Severity: High]
Does using IS_REACHABLE() here mask a Kconfig dependency mismatch?

If a user configures DRM_MSM=y and QCOM_SMEM=m, IS_REACHABLE() evaluates
to false and provides the inline stub to the built-in driver. Since the
callers abort on error rather than treating the configuration as optional,
won't this cause guaranteed runtime probe failures for built-in drivers
instead of catching the unmet dependency at build time?

>  const struct qcom_ubwc_cfg_data *qcom_ubwc_config_get_data(void);
>  #else
>  static inline const struct qcom_ubwc_cfg_data *qcom_ubwc_config_get_data(void)

[Severity: Medium]
This is a pre-existing issue, but does falling back to this stub cause
a resource leak during device probe?

Looking at a5xx_gpu_init(), if the stub is used and returns an error pointer,
the function returns early without cleaning up resources allocated by
adreno_gpu_init():

drivers/gpu/drm/msm/adreno/a5xx_gpu.c:a5xx_gpu_init() {
    ...
    adreno_gpu_init(dev, pdev, adreno_gpu, &funcs, 1);
    ...
    adreno_gpu->ubwc_config = qcom_ubwc_config_get_data();
    if (IS_ERR(adreno_gpu->ubwc_config))
        return ERR_CAST(adreno_gpu->ubwc_config);
    ...
}

Will this leak memory and GPU resources like ringbuffers and the a5xx_gpu
structure itself if it fails to call a5xx_destroy() on the error path?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260812151934.709198-1-daniel.baluta@nxp.com?part=3

Re: [PATCH v4 1/3] soc: qcom: ubwc: Fix link error when QCOM_SMEM=n

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The patch adds `depends on QCOM_SMEM` to `QCOM_UBWC_CONFIG` but misses that `VIDEO_QCOM_IRIS` unconditionally selects it, causing an unmet dependency warning and leaving the original linker error unfixed.
- [High] The conditional select in `DRM_MSM` creates a configuration where a built-in driver calls a function from a module, resulting in a linker error.
--

--- Patch [1]: [PATCH v4 1/3] soc: qcom: ubwc: Fix link error when QCOM_SMEM=n ---
commit a54f8c4ddffc0b9c1fbde97cc8f98242588a42bf
Author: Daniel Baluta <daniel.baluta@nxp.com>

soc: qcom: ubwc: Fix link error when QCOM_SMEM=n

DRM_MSM unconditionally selects QCOM_UBWC_CONFIG, which calls SMEM APIs,
causing a link error on non-Qcom platforms (e.g. SOC_IMX5). Make
QCOM_UBWC_CONFIG depend on QCOM_SMEM to make the requirement explicit, and
guard the select in DRM_MSM with ARCH_QCOM && QCOM_SMEM.

> diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
> index 09469d56513b0..1670dbc9464c6 100644
> --- a/drivers/gpu/drm/msm/Kconfig
> +++ b/drivers/gpu/drm/msm/Kconfig
> @@ -22,7 +22,7 @@ config DRM_MSM
>  	select TMPFS
>  	select QCOM_SCM
>  	select QCOM_PAS
> -	select QCOM_UBWC_CONFIG
> +	select QCOM_UBWC_CONFIG if ARCH_QCOM && QCOM_SMEM

[Severity: High]
Can this conditional select create a new configuration where a built-in driver
fails to link against a module?

If we compile with CONFIG_DRM_MSM=y, CONFIG_ARCH_QCOM=y, and
CONFIG_QCOM_SMEM=m, the select evaluates to 'm', forcing
CONFIG_QCOM_UBWC_CONFIG=m.

Because IS_ENABLED(CONFIG_QCOM_UBWC_CONFIG) evaluates to true for both 'y'
and 'm', built-in code like msm_mdss_init() in drivers/gpu/drm/msm/msm_mdss.c
will attempt to call the external qcom_ubwc_config_get_data() function:

include/linux/soc/qcom/ubwc.h:
#if IS_ENABLED(CONFIG_QCOM_UBWC_CONFIG)
const struct qcom_ubwc_cfg_data *qcom_ubwc_config_get_data(void);
...

At link time, vmlinux will fail to resolve this function because it resides
in the ubwc_config module.

>  	select WANT_DEV_COREDUMP
>  	select SND_SOC_HDMI_CODEC if SND_SOC
>  	select SYNC_FILE

[ ... ]

> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
> index fd4d4ecd2df0f..e0629e9328c87 100644
> --- a/drivers/soc/qcom/Kconfig
> +++ b/drivers/soc/qcom/Kconfig
> @@ -321,6 +321,7 @@ config QCOM_QMI_HELPERS
>  
>  config QCOM_UBWC_CONFIG
>  	tristate
> +	depends on QCOM_SMEM

[Severity: High]
Does this leave the linker error unfixed when CONFIG_VIDEO_QCOM_IRIS=y?

Looking at drivers/media/platform/qcom/iris/Kconfig, it unconditionally
selects QCOM_UBWC_CONFIG:

config VIDEO_QCOM_IRIS
    ...
    select QCOM_UBWC_CONFIG

If we compile with CONFIG_COMPILE_TEST=y, CONFIG_VIDEO_QCOM_IRIS=y, and
CONFIG_QCOM_SMEM=n, the unconditional select will force QCOM_UBWC_CONFIG to y
despite the new dependency.

This produces an unmet dependency warning and attempts to link ubwc_config.c,
which fails with the exact undefined reference to 'qcom_smem_*' APIs that
this patch intended to fix.

>  	help
>  	  Most Qualcomm SoCs feature a number of Universal Bandwidth Compression
>  	  (UBWC) engines across various IP blocks, which need to be initialized

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260812151934.709198-1-daniel.baluta@nxp.com?part=1