linux-kernel - Re: [PATCH] scsi: ufs: core: Fix link error when CONFIG

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: <CAHUa44E5-c_rN1omhuVteBt9idz_d91r1tRKNgB2=-AWQDP2Jw@mail.gmail.com>
Date: Tue, 2 Dec 2025 12:41:05 +0100
From: Jens Wiklander <jens.wiklander@...aro.org>
To: Bean Huo <beanhuo@...pp.de>
Cc: Bart Van Assche <bvanassche@....org>, "Martin K. Petersen" <martin.petersen@...cle.com>, 
	avri.altman@...disk.com, alim.akhtar@...sung.com, jejb@...ux.ibm.com, 
	can.guo@....qualcomm.com, beanhuo@...ron.com, linux-scsi@...r.kernel.org, 
	linux-kernel@...r.kernel.org, kernel test robot <lkp@...el.com>
Subject: Re: [PATCH] scsi: ufs: core: Fix link error when CONFIG_RPMB=m

Hi,

On Tue, Dec 2, 2025 at 10:13 AM Bean Huo <beanhuo@...pp.de> wrote:
>
> On Mon, 2025-12-01 at 16:53 -0800, Bart Van Assche wrote:
> > On 12/1/25 2:42 PM, Bean Huo wrote:
> > > On Mon, 2025-12-01 at 12:25 -0500, Martin K. Petersen wrote:
> > > > > When CONFIG_SCSI_UFSHCD=y and CONFIG_RPMB=m, the kernel fails to link
> > > > > with undefined references to ufs_rpmb_probe() and ufs_rpmb_remove():
> > > > >
> > > > >    ld: drivers/ufs/core/ufshcd.c:8950: undefined reference to
> > > > > `ufs_rpmb_probe'
> > > > >    ld: drivers/ufs/core/ufshcd.c:10505: undefined reference to
> > > > > `ufs_rpmb_remove'
> > > > >
> > > > > The issue occurs because IS_ENABLED(CONFIG_RPMB) evaluates to true
> > > > > when CONFIG_RPMB=m, causing the header to declare the real function
> > > > > prototypes.
> > > >
> > > > This now breaks the modular build for me.
> > >
> > > I tested both IS_BUILTIN and IS_REACHABLE for the RPMB dependencies both
> > > work
> > > correctly in my configuration.
> > >
> > > IS_REACHABLE would provide more flexibility for module configurations, but
> > > in
> > > practice, I don't have experience with UFS being used as a module.
> > >
> > > Would you prefer IS_REACHABLE for theoretical flexibility, or is IS_BUILTIN
> > > acceptable given the typical UFS built-in configuration?
> >
> > Hi Martin and Bean,
> >
> > Unless someone comes up with a better solution, I propose to apply this
> > patch before sending a pull request to Linus and look into making RPMB
> > tristate again at a later time:
> >
> > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > index 9d1de68dee27..e0b7f8fb6ecb 100644
> > --- a/drivers/misc/Kconfig
> > +++ b/drivers/misc/Kconfig
> > @@ -105,7 +105,7 @@ config PHANTOM
> >           say N here.
> >
> >   config RPMB
> > -       tristate "RPMB partition interface"
> > +       bool "RPMB partition interface"
> >         depends on MMC || SCSI_UFSHCD
> >         help
> >           Unified RPMB unit interface for RPMB capable devices such as eMMC
> > and
> >
> > Thanks,
> >
> > Bart.
>
> Hi Bart, Martin, (and Jens - adding you to this thread),
>
> Bart, thanks for the proposed solution to change RPMB from tristate
> to bool. This makes sense given our use case that UFS is typically
> built-in, and RPMB should follow the same pattern.
>
>
> Hi Jens,
>
> we wanted to make sure you're aware of this proposed change. The reasoning is:
> 1, avoids module dependency complexity between UFS and RPMB
> 2, matches typical usage where both are built-in
>
> Let me know if there are concerns with making RPMB bool instead of tristate.

We use "depends on RPMB || !RPMB" in drivers/tee/optee/Kconfig and
drivers/mmc/core/Kconfig to handle this problem. Could the same
pattern be used here?

Cheers,
Jens