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

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

[Bean Huo]

From: Bean Huo <beanhuo@micron.com>

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.
However, the Makefile line:

  ufshcd-core-$(CONFIG_RPMB) += ufs-rpmb.o

only adds ufs-rpmb.o when CONFIG_RPMB=y (builtin), not when CONFIG_RPMB=m.
This results in the functions being called but not linked into the kernel.

Fix this by changing IS_ENABLED() to IS_BUILTIN(), ensuring the real
functions are only declared when ufs-rpmb.o is actually compiled into
ufshcd-core.

Fixes: b06b8c421485 ("scsi: ufs: core: Add OP-TEE based RPMB driver for UFS devices")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202511300443.h7sotuL0-lkp@intel.com/
Signed-off-by: Bean Huo <beanhuo@micron.com>
---
 drivers/ufs/core/ufshcd-priv.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ufs/core/ufshcd-priv.h b/drivers/ufs/core/ufshcd-priv.h
index 4259f499382f..9bab6aada072 100644
--- a/drivers/ufs/core/ufshcd-priv.h
+++ b/drivers/ufs/core/ufshcd-priv.h
@@ -438,7 +438,7 @@ static inline u32 ufshcd_mcq_get_sq_head_slot(struct ufs_hw_queue *q)
 	return val / sizeof(struct utp_transfer_req_desc);
 }
 
-#if IS_ENABLED(CONFIG_RPMB)
+#if IS_BUILTIN(CONFIG_RPMB)
 int ufs_rpmb_probe(struct ufs_hba *hba);
 void ufs_rpmb_remove(struct ufs_hba *hba);
 #else
-- 
2.34.1

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

[Martin K. Petersen]

Hi Bean!

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

-- 
Martin K. Petersen

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

[Bean Huo]

On Mon, 2025-12-01 at 12:25 -0500, Martin K. Petersen wrote:
> 
> Hi Bean!
> 
> > 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.
> 

Hi Martin,

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?

Kind regards,
Bean

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

[Bart Van Assche]

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.

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

[Bean Huo]

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.


Kind regards,
Bean

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

[Jens Wiklander]

Hi,

On Tue, Dec 2, 2025 at 10:13 AM Bean Huo <beanhuo@iokpp.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

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

[Bean Huo]

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@iokpp.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?
> 

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.


Kind regards, 
Bean

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

[Jens Wiklander]

[+ Ulf and Arnd in CC]

On Tue, Dec 2, 2025 at 1:17 PM Bean Huo <beanhuo@iokpp.de> 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@iokpp.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?
> >
>
> 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? Are we moving the problem somewhere else?

Cheers,
Jens

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@iokpp.de> 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@iokpp.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:
>> > > > >
>> > > > > 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

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@iokpp.de> 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@iokpp.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?
> > > 
> > 
> > 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

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@iokpp.de> 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

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

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

[Bean Huo]

On Tue, 2025-12-02 at 16:47 +0100, Arnd Bergmann wrote:
> > > 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

Thanks, Just sent a new patch and CC you, please check.


Hi Martin, Bart, and Jens,

Following our discussion and Arnd's suggestion, I've submitted a new patch that
takes a different approach to fix the RPMB link error.

Martin, the new patch should handle your modular build configuration correctly
while fixing the reported link error.

Thanks for all the feedback.

Best regards,
Bean

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

[kernel test robot]

Hi Bean,

kernel test robot noticed the following build errors:

[auto build test ERROR on mkp-scsi/for-next]
[also build test ERROR on jejb-scsi/for-next mkp-scsi/6.19/scsi-queue next-20251202]
[cannot apply to linus/master v6.18]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Bean-Huo/scsi-ufs-core-Fix-link-error-when-CONFIG_RPMB-m/20251130-231759
base:   https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next
patch link:    https://lore.kernel.org/r/20251130151508.3076994-1-beanhuo%40iokpp.de
patch subject: [PATCH] scsi: ufs: core: Fix link error when CONFIG_RPMB=m
config: loongarch-allmodconfig (https://download.01.org/0day-ci/archive/20251203/202512031316.SvDwnvhy-lkp@intel.com/config)
compiler: clang version 19.1.7 (https://github.com/llvm/llvm-project cd708029e0b2869e80abe31ddb175f7c35361f90)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251203/202512031316.SvDwnvhy-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202512031316.SvDwnvhy-lkp@intel.com/

All errors (new ones prefixed by >>):

>> drivers/ufs/core/ufs-rpmb.c:135:5: error: redefinition of 'ufs_rpmb_probe'
     135 | int ufs_rpmb_probe(struct ufs_hba *hba)
         |     ^
   drivers/ufs/core/ufshcd-priv.h:445:19: note: previous definition is here
     445 | static inline int ufs_rpmb_probe(struct ufs_hba *hba)
         |                   ^
>> drivers/ufs/core/ufs-rpmb.c:234:6: error: redefinition of 'ufs_rpmb_remove'
     234 | void ufs_rpmb_remove(struct ufs_hba *hba)
         |      ^
   drivers/ufs/core/ufshcd-priv.h:449:20: note: previous definition is here
     449 | static inline void ufs_rpmb_remove(struct ufs_hba *hba)
         |                    ^
   2 errors generated.


vim +/ufs_rpmb_probe +135 drivers/ufs/core/ufs-rpmb.c

b06b8c421485e0 Bean Huo 2025-11-08  133  
b06b8c421485e0 Bean Huo 2025-11-08  134  /* UFS RPMB device registration */
b06b8c421485e0 Bean Huo 2025-11-08 @135  int ufs_rpmb_probe(struct ufs_hba *hba)
b06b8c421485e0 Bean Huo 2025-11-08  136  {
b06b8c421485e0 Bean Huo 2025-11-08  137  	struct ufs_rpmb_dev *ufs_rpmb, *it, *tmp;
b06b8c421485e0 Bean Huo 2025-11-08  138  	struct rpmb_dev *rdev;
b06b8c421485e0 Bean Huo 2025-11-08  139  	char *cid = NULL;
b06b8c421485e0 Bean Huo 2025-11-08  140  	int region;
b06b8c421485e0 Bean Huo 2025-11-08  141  	u32 cap;
b06b8c421485e0 Bean Huo 2025-11-08  142  	int ret;
b06b8c421485e0 Bean Huo 2025-11-08  143  
b06b8c421485e0 Bean Huo 2025-11-08  144  	if (!hba->ufs_rpmb_wlun || hba->dev_info.b_advanced_rpmb_en) {
b06b8c421485e0 Bean Huo 2025-11-08  145  		dev_info(hba->dev, "Skip OP-TEE RPMB registration\n");
b06b8c421485e0 Bean Huo 2025-11-08  146  		return -ENODEV;
b06b8c421485e0 Bean Huo 2025-11-08  147  	}
b06b8c421485e0 Bean Huo 2025-11-08  148  
b06b8c421485e0 Bean Huo 2025-11-08  149  	/* Check if device_id is available */
b06b8c421485e0 Bean Huo 2025-11-08  150  	if (!hba->dev_info.device_id) {
b06b8c421485e0 Bean Huo 2025-11-08  151  		dev_err(hba->dev, "UFS Device ID not available\n");
b06b8c421485e0 Bean Huo 2025-11-08  152  		return -EINVAL;
b06b8c421485e0 Bean Huo 2025-11-08  153  	}
b06b8c421485e0 Bean Huo 2025-11-08  154  
b06b8c421485e0 Bean Huo 2025-11-08  155  	INIT_LIST_HEAD(&hba->rpmbs);
b06b8c421485e0 Bean Huo 2025-11-08  156  
b06b8c421485e0 Bean Huo 2025-11-08  157  	struct rpmb_descr descr = {
b06b8c421485e0 Bean Huo 2025-11-08  158  		.type = RPMB_TYPE_UFS,
b06b8c421485e0 Bean Huo 2025-11-08  159  		.route_frames = ufs_rpmb_route_frames,
b06b8c421485e0 Bean Huo 2025-11-08  160  		.reliable_wr_count = hba->dev_info.rpmb_io_size,
b06b8c421485e0 Bean Huo 2025-11-08  161  	};
b06b8c421485e0 Bean Huo 2025-11-08  162  
b06b8c421485e0 Bean Huo 2025-11-08  163  	for (region = 0; region < ARRAY_SIZE(hba->dev_info.rpmb_region_size); region++) {
b06b8c421485e0 Bean Huo 2025-11-08  164  		cap = hba->dev_info.rpmb_region_size[region];
b06b8c421485e0 Bean Huo 2025-11-08  165  		if (!cap)
b06b8c421485e0 Bean Huo 2025-11-08  166  			continue;
b06b8c421485e0 Bean Huo 2025-11-08  167  
b06b8c421485e0 Bean Huo 2025-11-08  168  		ufs_rpmb = devm_kzalloc(hba->dev, sizeof(*ufs_rpmb), GFP_KERNEL);
b06b8c421485e0 Bean Huo 2025-11-08  169  		if (!ufs_rpmb) {
b06b8c421485e0 Bean Huo 2025-11-08  170  			ret = -ENOMEM;
b06b8c421485e0 Bean Huo 2025-11-08  171  			goto err_out;
b06b8c421485e0 Bean Huo 2025-11-08  172  		}
b06b8c421485e0 Bean Huo 2025-11-08  173  
b06b8c421485e0 Bean Huo 2025-11-08  174  		ufs_rpmb->hba = hba;
b06b8c421485e0 Bean Huo 2025-11-08  175  		ufs_rpmb->dev.parent = &hba->ufs_rpmb_wlun->sdev_gendev;
b06b8c421485e0 Bean Huo 2025-11-08  176  		ufs_rpmb->dev.bus = &ufs_rpmb_bus_type;
b06b8c421485e0 Bean Huo 2025-11-08  177  		ufs_rpmb->dev.release = ufs_rpmb_device_release;
b06b8c421485e0 Bean Huo 2025-11-08  178  		dev_set_name(&ufs_rpmb->dev, "ufs_rpmb%d", region);
b06b8c421485e0 Bean Huo 2025-11-08  179  
b06b8c421485e0 Bean Huo 2025-11-08  180  		/* Set driver data BEFORE device_register */
b06b8c421485e0 Bean Huo 2025-11-08  181  		dev_set_drvdata(&ufs_rpmb->dev, ufs_rpmb);
b06b8c421485e0 Bean Huo 2025-11-08  182  
b06b8c421485e0 Bean Huo 2025-11-08  183  		ret = device_register(&ufs_rpmb->dev);
b06b8c421485e0 Bean Huo 2025-11-08  184  		if (ret) {
b06b8c421485e0 Bean Huo 2025-11-08  185  			dev_err(hba->dev, "Failed to register UFS RPMB device %d\n", region);
b06b8c421485e0 Bean Huo 2025-11-08  186  			put_device(&ufs_rpmb->dev);
b06b8c421485e0 Bean Huo 2025-11-08  187  			goto err_out;
b06b8c421485e0 Bean Huo 2025-11-08  188  		}
b06b8c421485e0 Bean Huo 2025-11-08  189  
b06b8c421485e0 Bean Huo 2025-11-08  190  		/* Create unique ID by appending region number to device_id */
b06b8c421485e0 Bean Huo 2025-11-08  191  		cid = kasprintf(GFP_KERNEL, "%s-R%d", hba->dev_info.device_id, region);
b06b8c421485e0 Bean Huo 2025-11-08  192  		if (!cid) {
b06b8c421485e0 Bean Huo 2025-11-08  193  			device_unregister(&ufs_rpmb->dev);
b06b8c421485e0 Bean Huo 2025-11-08  194  			ret = -ENOMEM;
b06b8c421485e0 Bean Huo 2025-11-08  195  			goto err_out;
b06b8c421485e0 Bean Huo 2025-11-08  196  		}
b06b8c421485e0 Bean Huo 2025-11-08  197  
b06b8c421485e0 Bean Huo 2025-11-08  198  		descr.dev_id = cid;
b06b8c421485e0 Bean Huo 2025-11-08  199  		descr.dev_id_len = strlen(cid);
b06b8c421485e0 Bean Huo 2025-11-08  200  		descr.capacity = cap;
b06b8c421485e0 Bean Huo 2025-11-08  201  
b06b8c421485e0 Bean Huo 2025-11-08  202  		/* Register RPMB device */
b06b8c421485e0 Bean Huo 2025-11-08  203  		rdev = rpmb_dev_register(&ufs_rpmb->dev, &descr);
b06b8c421485e0 Bean Huo 2025-11-08  204  		if (IS_ERR(rdev)) {
b06b8c421485e0 Bean Huo 2025-11-08  205  			dev_err(hba->dev, "Failed to register UFS RPMB device.\n");
b06b8c421485e0 Bean Huo 2025-11-08  206  			device_unregister(&ufs_rpmb->dev);
b06b8c421485e0 Bean Huo 2025-11-08  207  			ret = PTR_ERR(rdev);
b06b8c421485e0 Bean Huo 2025-11-08  208  			goto err_out;
b06b8c421485e0 Bean Huo 2025-11-08  209  		}
b06b8c421485e0 Bean Huo 2025-11-08  210  
b06b8c421485e0 Bean Huo 2025-11-08  211  		kfree(cid);
b06b8c421485e0 Bean Huo 2025-11-08  212  		cid = NULL;
b06b8c421485e0 Bean Huo 2025-11-08  213  
b06b8c421485e0 Bean Huo 2025-11-08  214  		ufs_rpmb->rdev = rdev;
b06b8c421485e0 Bean Huo 2025-11-08  215  		ufs_rpmb->region_id = region;
b06b8c421485e0 Bean Huo 2025-11-08  216  
b06b8c421485e0 Bean Huo 2025-11-08  217  		list_add_tail(&ufs_rpmb->node, &hba->rpmbs);
b06b8c421485e0 Bean Huo 2025-11-08  218  
b06b8c421485e0 Bean Huo 2025-11-08  219  		dev_info(hba->dev, "UFS RPMB region %d registered (capacity=%u)\n", region, cap);
b06b8c421485e0 Bean Huo 2025-11-08  220  	}
b06b8c421485e0 Bean Huo 2025-11-08  221  
b06b8c421485e0 Bean Huo 2025-11-08  222  	return 0;
b06b8c421485e0 Bean Huo 2025-11-08  223  err_out:
b06b8c421485e0 Bean Huo 2025-11-08  224  	kfree(cid);
b06b8c421485e0 Bean Huo 2025-11-08  225  	list_for_each_entry_safe(it, tmp, &hba->rpmbs, node) {
b06b8c421485e0 Bean Huo 2025-11-08  226  		list_del(&it->node);
b06b8c421485e0 Bean Huo 2025-11-08  227  		device_unregister(&it->dev);
b06b8c421485e0 Bean Huo 2025-11-08  228  	}
b06b8c421485e0 Bean Huo 2025-11-08  229  
b06b8c421485e0 Bean Huo 2025-11-08  230  	return ret;
b06b8c421485e0 Bean Huo 2025-11-08  231  }
b06b8c421485e0 Bean Huo 2025-11-08  232  
b06b8c421485e0 Bean Huo 2025-11-08  233  /* UFS RPMB remove handler */
b06b8c421485e0 Bean Huo 2025-11-08 @234  void ufs_rpmb_remove(struct ufs_hba *hba)
b06b8c421485e0 Bean Huo 2025-11-08  235  {
b06b8c421485e0 Bean Huo 2025-11-08  236  	struct ufs_rpmb_dev *ufs_rpmb, *tmp;
b06b8c421485e0 Bean Huo 2025-11-08  237  
b06b8c421485e0 Bean Huo 2025-11-08  238  	if (list_empty(&hba->rpmbs))
b06b8c421485e0 Bean Huo 2025-11-08  239  		return;
b06b8c421485e0 Bean Huo 2025-11-08  240  
b06b8c421485e0 Bean Huo 2025-11-08  241  	/* Remove all registered RPMB devices */
b06b8c421485e0 Bean Huo 2025-11-08  242  	list_for_each_entry_safe(ufs_rpmb, tmp, &hba->rpmbs, node) {
b06b8c421485e0 Bean Huo 2025-11-08  243  		dev_info(hba->dev, "Removing UFS RPMB region %d\n", ufs_rpmb->region_id);
b06b8c421485e0 Bean Huo 2025-11-08  244  		/* Remove from list first */
b06b8c421485e0 Bean Huo 2025-11-08  245  		list_del(&ufs_rpmb->node);
b06b8c421485e0 Bean Huo 2025-11-08  246  		/* Unregister device */
b06b8c421485e0 Bean Huo 2025-11-08  247  		device_unregister(&ufs_rpmb->dev);
b06b8c421485e0 Bean Huo 2025-11-08  248  	}
b06b8c421485e0 Bean Huo 2025-11-08  249  
b06b8c421485e0 Bean Huo 2025-11-08  250  	dev_info(hba->dev, "All UFS RPMB devices unregistered\n");
b06b8c421485e0 Bean Huo 2025-11-08  251  }
b06b8c421485e0 Bean Huo 2025-11-08  252  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

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

[Arnd Bergmann]

On Wed, Dec 3, 2025, at 07:15, kernel test robot wrote:
>
> All errors (new ones prefixed by >>):
>
>>> drivers/ufs/core/ufs-rpmb.c:135:5: error: redefinition of 'ufs_rpmb_probe'
>      135 | int ufs_rpmb_probe(struct ufs_hba *hba)
>          |     ^
>    drivers/ufs/core/ufshcd-priv.h:445:19: note: previous definition is here
>      445 | static inline int ufs_rpmb_probe(struct ufs_hba *hba)
>          |                   ^
>>> drivers/ufs/core/ufs-rpmb.c:234:6: error: redefinition of 'ufs_rpmb_remove'

The declaration and definitio are inconsistent: the former is inside of
an #ifdef block, the latter is not. I think either way works, but it
needs to be the same for both.

     Arnd

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

[Bean Huo]

On Wed, 2025-12-03 at 15:39 +0100, Arnd Bergmann wrote:
> On Wed, Dec 3, 2025, at 07:15, kernel test robot wrote:
> > 
> > All errors (new ones prefixed by >>):
> > 
> > > > drivers/ufs/core/ufs-rpmb.c:135:5: error: redefinition of
> > > > 'ufs_rpmb_probe'
> >       135 | int ufs_rpmb_probe(struct ufs_hba *hba)
> >           |     ^
> >     drivers/ufs/core/ufshcd-priv.h:445:19: note: previous definition is here
> >       445 | static inline int ufs_rpmb_probe(struct ufs_hba *hba)
> >           |                   ^
> > > > drivers/ufs/core/ufs-rpmb.c:234:6: error: redefinition of
> > > > 'ufs_rpmb_remove'
> 
> The declaration and definitio are inconsistent: the former is inside of
> an #ifdef block, the latter is not. I think either way works, but it
> needs to be the same for both.
> 
>      Arnd


Hi Arnd,

I was reviewing the kernel test robot output regarding the ufs_rpmb_probe and
ufs_rpmb_remove redefinition errors, and I wanted to clarify my understanding

From what I see in the source:

   
   #if IS_ENABLED(CONFIG_RPMB)
   int ufs_rpmb_probe(struct ufs_hba *hba);
   void ufs_rpmb_remove(struct ufs_hba *hba);
   #else
   static inline int ufs_rpmb_probe(struct ufs_hba *hba) { return 0; }
   static inline void ufs_rpmb_remove(struct ufs_hba *hba) { }
   #endif

my understanding is that if CONFIG_RPMB=n, compilation goes into the #else
branch, which emits static inline stubs, so ufs-rpmb.c should not be compiled at
all because of ufshcd-core-$(CONFIG_RPMB) += ufs-rpmb.o in the Makefile.

However, the robot reported redefinition errors, which suggests that the
header’s #else branch is being included while ufs-rpmb.c is also being compiled.

I’m wondering if I’m missing something about the robot’s build logic.


Thanks,
Bean

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

[Arnd Bergmann]

On Wed, Dec 3, 2025, at 17:23, Bean Huo wrote:
> On Wed, 2025-12-03 at 15:39 +0100, Arnd Bergmann wrote:
>
> However, the robot reported redefinition errors, which suggests that the
> header’s #else branch is being included while ufs-rpmb.c is also being compiled.
>
> I’m wondering if I’m missing something about the robot’s build logic.
>

It took me a while as well, but I found the link to the patch that
was tested now, as this was the one that changed IS_ENABLED()
to IS_BUILTIN(), and that went wrong with CONFIG_RPMB=m.

    Arnd