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

[Bean Huo]

On Tue, 2025-12-02 at 14:25 +0100, Arnd Bergmann wrote:
> On Tue, Dec 2, 2025, at 14:17, Jens Wiklander wrote:
> > 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:
> > > > > > > 
> > > > > > > Would you prefer IS_REACHABLE for theoretical flexibility, or is
> > > > > > > IS_BUILTIN
> > > > > > > acceptable given the typical UFS built-in configuration?
> > > > > > 
> 
> I did introduce IS_REACHABLE() a long time ago, but I consider it
> the wrong approach for almost every possible case, as it only
> works around link failures by introducing very unexpected runtime
> behavior.

thanks for your info.

> 
> > > > > > 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
> 
> This equally does not seem appropriate, as others have commented.
> 

the qeustions do we need to make RPMB as a module?

> > > > > 
> > > > > 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?
> 
> This does sound like the right idea.
> 
> > > 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? Are we moving the problem somewhere else?
> 
> My first impression is that the 'depends on MMC || SCSI_UFSHCD' is
> the problem here, and I would suggest simply dropping that dependency.
> 

> Any module that links against exported RPMB symbols should have
> the 'depends on RPMB || !RPMB' line to enable linking correctly.
> The RPMB implementation in drivers/misc on the other hand has no
> link-time dependency I can see, and enabling it without one of
> the other symbols simply means that there is a module that does
> nothing.

I have added this option in my previous email, can you add which one you prefer.

Kind regards,
Bean

> 
>      Arnd