Hi Alexey, On 2026-09-18T06:35:41, Alexey Charkov <[email protected]> wrote: > ufs: expose the boot logical unit as a block device > > The boot W-LU aliases whichever logical unit bBootLunEn currently selects, > so reading through it follows an A/B switch made by the device itself > rather than one U-Boot has to work out. > > Leave the device and RPMB well known units alone: neither is a block > device, so probing them would only cost two failed round trips.
Please can you also mention that this applies to every UFS board, in both SPL and U-Boot proper, and that the new device only appears when bBootLunEn is non-zero? At present the message reads as though nothing changes for existing users. > > Signed-off-by: Alexey Charkov <[email protected]> > > drivers/ufs/ufs-uclass.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > diff --git a/drivers/ufs/ufs-uclass.c b/drivers/ufs/ufs-uclass.c > @@ -2211,6 +2218,8 @@ int ufshcd_probe(struct udevice *ufs_dev, struct > ufs_hba_ops *hba_ops) > scsi_plat->max_bytes_per_req = UFS_MAX_BYTES; > + scsi_plat->wluns = ufs_wluns; > + scsi_plat->wlun_count = ARRAY_SIZE(ufs_wluns); This is unconditional, so every board with boot enabled on its UFS device gets a second block device presenting the same medium as an existing LU. The only user in this series is the SPL option in the next patch. I have a few concerns with that: 1. do_scsi_scan_one() calls bootdev_setup_for_sibling_blk() for the new device, so bootstd scans the same medium twice and EFI gets two disks with identical contents. I suspect that matters where the boot LUs carry a GPT, since the partition UUIDs are then duplicated. 2. The block cache is keyed on uclass and devnum, so blk_dwrite() to the real LU only invalidates that devnum. A later read through the W-LU (or the other way around) can return stale data. 3. The renumbering described on patch 4 can break boot_targets and 'scsi dev N' in existing environments, and it depends on whether bBootLunEn is set on the particular device. How about putting this behind a Kconfig option (with an SPL variant) which SPL_UFS_RAW_U_BOOT_USE_BOOT_WLUN selects, so that only boards which want the boot W-LU get it? With IS_ENABLED() the table can stay as it is. What do you think? BTW, as far as I know Linux registers the W-LUs as SCSI devices but sd does not bind to them, so they never appear as disks there. Regards, Simon
