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

[Arnd Bergmann]

On Tue, Dec 2, 2025, at 15:59, Bean Huo wrote:
> On Tue, 2025-12-02 at 14:25 +0100, Arnd Bergmann wrote:
>> On Tue, Dec 2, 2025, at 14:17, Jens Wiklander wrote:
>> > > > > > 
>> > > > > >   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?

I think generally speaking, yes: Everything that can be made a
loadable module should be configurable that way.

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

You suggested:
 "1. Make RPMB not directly depend on SCSI_UFSHCD in Kconfig then,
   Use "depends on RPMB || !RPMB" in SCSI_UFSHCD (like MMC does)"

but I think we should go a step further and remove the
'depends on MMC' as well for consistency. Otherwise you create
a dependency chain that makes it impossible to have UFSHCD
built-in if MMC is a loadable module.

    Arnd