drivers/ufs/core/ufshcd-priv.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
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.1Hi 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
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
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
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
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
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
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.
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
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
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
[+ 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
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
© 2016 - 2026 Red Hat, Inc.