Linux kernel and device drivers for NXP i.MX platforms
 help / color / mirror / Atom feed
From: Daniel Baluta <daniel.baluta@oss.nxp.com>
To: Nathan Chancellor <nathan@kernel.org>,
	Daniel Baluta <daniel.baluta@nxp.com>
Cc: andersson@kernel.org, konradybcio@kernel.org,
	robin.clark@oss.qualcomm.com, dmitry.baryshkov@oss.qualcomm.com,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
	imx@lists.linux.dev
Subject: Re: [PATCH v4 0/3] soc: qcom: ubwc: Fix link error
Date: Fri, 14 Aug 2026 09:42:52 +0300	[thread overview]
Message-ID: <0b9128de-e2d9-4271-97b8-9fa0c7f6fa3c@oss.nxp.com> (raw)
In-Reply-To: <20260813232350.GA312295@ax162>

On 8/14/26 02:23, Nathan Chancellor wrote:
> [You don't often get email from nathan@kernel.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> Hi Daniel,
> 
> On Wed, Aug 12, 2026 at 06:19:31PM +0300, Daniel Baluta wrote:
>> 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
> 
> I think this patch should come first since you introduce the QCOM_SMEM
> dependency that requires this change in the first patch, which could
> mess with bisects. I would personally add the 'if' condition to the
> 'select QCOM_UBWC_CONFIG' statements in one patch then add the QCOM_SMEM
> dependency to QCOM_UBWC_CONFIG in a separate patch.
> 
>>   soc: qcom: ubwc: Use IS_REACHABLE() instead of IS_ENABLED()
> 
> Even with this series applied, I see
> 
>   $ cat allno.config
>   CONFIG_ARCH_MULTI_V7=y
>   CONFIG_ARCH_QCOM=y
>   CONFIG_DRM=y
>   CONFIG_DRM_MSM=y
>   CONFIG_DRM_MSM_DPU=y
>   CONFIG_IOMMU_SUPPORT=y
>   CONFIG_MAILBOX=y
>   CONFIG_MMU=y
>   CONFIG_PM=y
>   CONFIG_QCOM_AOSS_QMP=y
>   CONFIG_QCOM_LLCC=y
>   CONFIG_QCOM_OCMEM=y
> 
>   $ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- KCONFIG_ALLCONFIG=1 allnoconfig drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp_v13.o
>   In file included from drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp_v13.c:7:
>   include/linux/soc/qcom/ubwc.h: In function 'qcom_ubwc_config_get_data':
>   include/linux/soc/qcom/ubwc.h:45:16: error: implicit declaration of function 'ERR_PTR' [-Wimplicit-function-declaration]
>      45 |         return ERR_PTR(-EOPNOTSUPP);
>         |                ^~~~~~~
>   include/linux/soc/qcom/ubwc.h:45:25: error: 'EOPNOTSUPP' undeclared (first use in this function)

Hi Nathan,

This issue is pre-existing and I've sent a separate fix for it:

https://lore.kernel.org/all/5fy7l6o5nfzclsmhsqys562xwoilbo4xv3af65kcqugtitgltd@3fw2w443pw2g/#r


      reply	other threads:[~2026-08-14  6:39 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-12 15:19 [PATCH v4 0/3] soc: qcom: ubwc: Fix link error Daniel Baluta
2026-08-12 15:19 ` [PATCH v4 1/3] soc: qcom: ubwc: Fix link error when QCOM_SMEM=n Daniel Baluta
2026-08-12 15:50   ` sashiko-bot
2026-08-13  5:32     ` Daniel Baluta
2026-08-12 15:19 ` [PATCH v4 2/3] media: iris: Fix unmet dependency " Daniel Baluta
2026-08-12 15:19 ` [PATCH v4 3/3] soc: qcom: ubwc: Use IS_REACHABLE() instead of IS_ENABLED() Daniel Baluta
2026-08-12 15:32   ` sashiko-bot
2026-08-13 23:23 ` [PATCH v4 0/3] soc: qcom: ubwc: Fix link error Nathan Chancellor
2026-08-14  6:42   ` Daniel Baluta [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=0b9128de-e2d9-4271-97b8-9fa0c7f6fa3c@oss.nxp.com \
    --to=daniel.baluta@oss.nxp.com \
    --cc=andersson@kernel.org \
    --cc=daniel.baluta@nxp.com \
    --cc=dmitry.baryshkov@oss.qualcomm.com \
    --cc=imx@lists.linux.dev \
    --cc=konradybcio@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nathan@kernel.org \
    --cc=robin.clark@oss.qualcomm.com \
    /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