initcall_blacklist=ufshcd_core_init on duchamp (Poco X6 Pro) permanently blocks UFS storage enumeration on a standalone-built boot image (stock kernel source)

Device: duchamp (Poco X6 Pro), MT6897/Dimensity 8300

Kernel: Built from Xiaomi's own published stock source (kernel-6.1-stock-6.1.25, kernel_device_modules-6.1), using MotorolaMobilityLLC's public bazel_mgk_rules as the Kleaf/Bazel build scaffolding (Xiaomi doesn't publish their own Bazel build harness for this device), flashed standalone outside the official OTA/MIUI build pipeline.

Issue:
LK/preloader injects initcall_blacklist=ufshcd_core_init into the kernel command line at boot. Confirmed via dmesg (Kernel command line: ... initcall_blacklist=ufshcd_core_init ...) that this string is not present in our own vendor_boot cmdline, vendor bootconfig, or the decompiled DTB /chosen/bootargs — so it's injected downstream of vendor_boot, presumably by LK itself.

This blacklists ufshcd_core_init() in drivers/ufs/core/ufshcd.c, which is solely responsible for:

ret = scsi_register_driver(&ufs_dev_wlun_template.gendrv);

Without this registration, the UFS device WLUN (well-known LUN, address 0x50, SCSI id 49488) never gets a matching driver, so ufshcd_wl_probe() never runs, and its device_link (created in ufshcd_setup_links(), supplier = device WLUN, consumers = all other LUNs including boot/data partitions and RPMB) never reaches DL_STATE_AVAILABLE.

Result: every real storage LUN (0, 1, 2 in our case) sits permanently in deferred probe, confirmed via /sys/kernel/debug/devices_deferred:

0:0:0:0 scsi: supplier 0:0:0:49488 not ready
0:0:0:1 scsi: supplier 0:0:0:49488 not ready
0:0:0:2 scsi: supplier 0:0:0:49488 not ready

No block devices ever appear under /dev/block, init hangs waiting for boot_a/metadata/super/vbmeta_a uevents that never come.

Checked and ruled out:

All kernel modules load correctly, including ufs-mediatek-mod.ko, in correct dependency order
UFS host controller (ufshci@112b0000) fully probes — clocks, IRQs, vcc/vccq regulators resolve fine
SCSI transport works — Micron MT512GAYAX4U40 enumerates correctly, all LUNs including WLUNs appear
Not a Kconfig gap — CONFIG_SCSI_UFS_BSG, CONFIG_BLK_DEV_BSGLIB both set correctly
Searched kernel_device_modules-6.1 for any relocation/override of ufs_dev_wlun_template or scsi_register_driver that might compensate for the blacklist elsewhere — none found

Question: Does stock MIUI's kernel carry a patch that moves this WLUN driver registration out of the blacklisted initcall (e.g. into ufshcd-mtk's own platform probe, which isn't blacklisted and probes fine)? Or does LK only apply this blacklist under specific bootmodes rather than unconditionally? Any pointer to how stock avoids this would help a lot — happy to test/verify.

Start with drivers/ufs/core/ufshcd.c and trace ufshcd_core_init(), ufs_dev_wlun_template, and ufshcd_wl_probe(). Reproduce the boot with the reported command line and inspect /sys/kernel/debug/devices_deferred and dmesg. Done means establishing whether the stock kernel or LK provides a different registration path or boot-mode-specific blacklist behavior, with evidence from the relevant source or boot logs.