Re: [PATCH] scsi: ufs: core: Fix link error when CONFIG_RPMB=m

[Bean Huo]

On Tue, 2025-12-02 at 14:17 +0100, Jens Wiklander wrote:
> [+ Ulf and Arnd in CC]
> 
> On Tue, Dec 2, 2025 at 1:17 PM Bean Huo <beanhuo@xxxxxxxx> wrote:
> > 
> > On Tue, 2025-12-02 at 12:41 +0100, Jens Wiklander wrote:
> > > Hi,
> > > 
> > > On Tue, Dec 2, 2025 at 10:13 AM Bean Huo <beanhuo@xxxxxxxx> 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?
> > > 
> > 
> > Jens,
> > 
> > The pattern/dependecy used in MMC and OP-TEE doesn't apply UFS due to
> > different
> > dependency structures:
> > 
> > MMC: The core MMC config doesn't depend on RPMB. Only MMC_BLOCK (a sub-
> > layer)
> > has "depends on RPMB || !RPMB", avoiding the cycle.
> > 
> > OP-TEE: RPMB doesn't depend on OPTEE, so "depends on RPMB || !RPMB" in OPTEE
> > creates no cycle.
> > 
> > and for UFS:
> > 
> > UFS: This creates a direct circular dependency:
> > 
> > drivers/misc/Kconfig: RPMB depends on SCSI_UFSHCD
> > drivers/ufs/Kconfig: SCSI_UFSHCD depends on RPMB
> > 
> > This is why Bart's suggestion to make RPMB bool instead of tristate may be
> > the
> > cleaner solution.
> > 
> 
> What will that mean for OPTEE and MMC? That they can't be modules if
> RPMB is enabled? 

making RPMB bool would force it to be built-in, losing the modularity that MMC
and OPTEE currently have.

I'm wondering if the RPMB Kconfig dependency on SCSI_UFSHCD is necessary, or if
it's just expressing "RPMB needs a backend"?

Could we:
1. Make RPMB not directly depend on SCSI_UFSHCD in Kconfig then, Use "depends on
RPMB || !RPMB" in SCSI_UFSHCD (like MMC does)
2. Use IS_REACHABLE or IS_BUILTIN in the code

This would preserve RPMB modularity while handling the dependency correctly.
Thoughts?



> Are we moving the problem somewhere else?

No, we thought RPMB is a security feature, where built-in is often preferred.
what kind of senarios which need to make RPMB as moudle, do you know?



Kind regards,
Bean


> 
> Cheers,
> Jens