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

[Arnd Bergmann]

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:
>> > 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:
>> > > > >
>> > > > > 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?
>> > > >

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.

>> > > > 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.

>> > >
>> > > 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.

     Arnd