From nobody Wed Sep 24 02:32:51 2025 X-Original-To: freebsd-scsi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cWgqQ57cBz68KGd for ; Wed, 24 Sep 2025 02:32:34 +0000 (UTC) (envelope-from jaeyoon@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cWgqQ4bBbz3HV0 for ; Wed, 24 Sep 2025 02:32:34 +0000 (UTC) (envelope-from jaeyoon@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1758681154; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=8m2YMwb9gq6oNeb/eIW8lkpr9cUUvV2W+9tU8AfmALA=; b=VOjxYix1dp+eXddtFAiYgSmR2tqmQNsQ5RKdA15Spl06LN7TfhYvfu/ClGXOh4GQxk8MA6 K0iZzDO390eTunJLodiA+RyJz94JrY5Ylop0UHoK4hZhpaJiAG6yoWs25yhJ3Uhv6VNc2K x5Y11c3vtwaxz5awRrCPu1PTNwynsMEc8AudMcXZypOUi3Q0aJD0i0NYneu1tBi9hxLKDX PPMqZTOIBdpuZMWRoha1rFdCAJCdlMM8M7rlwqJAri1yv+Ju8vvG62gpVqD3dc5AjnKx1Q ZQzDzFox6k64JiJt6dFlJpGEMrGpIpF355UcPGEgNgct3fGw6RUIFNc5UPavZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1758681154; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=8m2YMwb9gq6oNeb/eIW8lkpr9cUUvV2W+9tU8AfmALA=; b=buUERmw7PYIRyBe38FjLuwltqXq5mUdd08jiWEOWXnZXW3rrkUiK74dqJL+gXtMRhAOUe3 IRUWFw54AcqOc9Vb3nrCdjrMm7KMjOSOdQ5qXSC/BUwT5Z4Z+Y9w07bl6Uy1aLdO6P0BQI HJIHZn4SxpNJiMWwspoJ6DmoaMtvO1muefg5x+ylvFeea0fugdEJLPNTybaX+J7qy1nMtf XK6B2+m8jkzERAZiIrLvB92Lmf03u2h/Ez7CN2SbbjCJQhPRQAOEPGimgOC8P/zWdJsOJO KCnXvHJhAK5L50VwZwgUeYzud0gWlNLWguA+DLmwaeejGP9vNhcLbXZAq9U8gg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758681154; a=rsa-sha256; cv=none; b=vpmRivmT4ILzrv4UY5i1RuZhzy3iuYnE0TuPKJK426Rxtmj7DRzPcL8BwLYW6VH6Y8AYBj /6gpT5hIeei84jswzc3REPtwXxOsxWoAiY8ELL1FtMJndc1qLf08XR99+PuYq/mb4LMaU+ gKfwbQi+Eo9GpsMAKvvaQIKKq4daJKGvnT/m04rWySRmkdrlIPpfvYqxNo5xotI9SNmm+3 nkNQ5/o+9mx+BLLjpsJGynf1bIEND/5dwQfvfDa18KyHZrU+eGfWyjzvlbd1fI0FOrKxHN rMCeKfLWV5dXZGigmpdG/Yr0HMdE62BGPQCLzEAWS7lUUoeyTIu84agdqwebjw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from mail-pg1-f182.google.com (mail-pg1-f182.google.com [209.85.215.182]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) (Authenticated sender: jaeyoon) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cWgqQ3nx2zBLV for ; Wed, 24 Sep 2025 02:32:34 +0000 (UTC) (envelope-from jaeyoon@freebsd.org) Received: by mail-pg1-f182.google.com with SMTP id 41be03b00d2f7-b4755f37c3eso5829143a12.3 for ; Tue, 23 Sep 2025 19:32:34 -0700 (PDT) X-Gm-Message-State: AOJu0YyP8ta4uFELCQHus/BxYgM2bEfY33t6trv02j5kXvRRCQF3UX8/ qX5VG/nMo4scWjukMzwGucUFKDmNxHo9prf2V8b6TfGG5OyuALlb4bgphQ42NYZZom1Q68/6iOM jIBQsFhdmOZ28+8+z3VC2SsYW7pPrc8Q= X-Google-Smtp-Source: AGHT+IG5xsc8oJDb0P59c0Ex7mYohJZphXFbcLJ2YHpWNWFJrUkwEXZH77VSzjmf52YqFhQY7iXXGaFT45TFuEFfKsg= X-Received: by 2002:a17:903:240f:b0:276:484c:dc57 with SMTP id d9443c01a7336-27cc6e4056cmr67303375ad.49.1758681153252; Tue, 23 Sep 2025 19:32:33 -0700 (PDT) List-Id: SCSI subsystem List-Archive: https://lists.freebsd.org/archives/freebsd-scsi List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-scsi@freebsd.org Sender: owner-freebsd-scsi@FreeBSD.org MIME-Version: 1.0 From: Jaeyoon Choi Date: Wed, 24 Sep 2025 11:32:51 +0900 X-Gmail-Original-Message-ID: X-Gm-Features: AS18NWAu3wPfI2HzVlIDP4H50tuA8J4Dxax6QcB3v37a3_OsxsF1nmHUhP3W4eM Message-ID: Subject: Questions about probing WLUNs for UFS power management To: freebsd-scsi@freebsd.org, imp@bsdimp.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello freebsd-scsi, I=E2=80=99m trying to implement Well-known LUNs (WLUNs) for the UFS (Univer= sal Flash Storage, ufshci(4)) driver, but the current SCSI XPT doesn't probe WLUNs, so I have a few questions. First, Well-known LUNs are defined in SCSI SAM-5. In UFS, 'REPORT LUNS', 'UFS Device', 'RPMB', and 'BOOT' LUNs are treated as WLUNs. (SAM-5 4.7.5.1 "Well-known logical unit addressing", UFS 2.1 spec 10.8.5 "10.8.5 Well Known Logical Unit Defined in UFS") Because a UFS device contains multiple LUNs, power management requires sending a START STOP UNIT(SSU) command to the 'UFS Device' WLUN. (If SSU is sent to a non-WLUN (normal) LUN, the device power mode is not changed and only that LUN becomes disabled.) (UFS 2.1 spec 7.4.2 "Power Management Command: START STOP UNIT") In FreeBSD, the SCSI XPT logic that parses LUNs checks the 'Simple logical unit addressing format' (SAM-5 Table 26) and the 8-byte 'Extended logical unit addressing format' (SAM-5 Table 35), but it does not check the 'Well-known logical unit extended addressing format' (SAM-5 Table 37). In the scsi_xpt.c code below, CAM_GET_LUN reads Extended LUNs and CAM_GET_SIMPLE_LUN reads Simple LUNs: ``` sys/cam/scsi/scsi_xpt.c line:2114 static void scsi_scan_bus(struct cam_periph *periph, union ccb *request_ccb) ... while (scan_info->lunindex[target_id] < nluns) { if (scan_info->cpi->hba_misc & PIM_EXTLUNS) { CAM_GET_LUN(target->luns, scan_info->lunindex[target_id], lun_id); break; } if (CAM_CAN_GET_SIMPLE_LUN(target->luns, scan_info->lunindex[target_id])) { CAM_GET_SIMPLE_LUN(target->luns, scan_info->lunindex[target_id], lun_id); break; } scan_info->lunindex[target_id]++; } ``` Also, we can obtain the number of WLUNs via the REPORT LUNS SCSI command. To retrieve WLUNs, the SELECT REPORT field must be set to 0x01, but SCSI XPT currently uses 0x00 to obtain only normal LUNs. (UFS 2.1 spec 11.3.12.2 "Report LUNS Command Select Report Field Values") ``` sys/cam/scsi/scsi_xpt.c line:827 static void probestart(struct cam_periph *periph, union ccb *start_ccb) ... case PROBE_REPORT_LUNS: ... scsi_report_luns(csio, 5, probedone, MSG_SIMPLE_Q_TAG, RPL_REPORT_DEFAULT, rp, periph->path->target->rpl_size, SSD_FULL_SIZE, 60000); ``` ``` sys/cam/scsi/scsi_all.h line:3020 struct scsi_report_luns { uint8_t opcode; uint8_t reserved1; #define RPL_REPORT_DEFAULT 0x00 #define RPL_REPORT_WELLKNOWN 0x01 ``` Looking at the Linux code, Linux also does not check WLUNs at the SCSI layer. Therefore, the Linux UFS driver explicitly registers the WLUNs during initialization by calling __scsi_add_device() ``` drivers/ufs/core/ufshcd.c line:8137 /** * ufshcd_scsi_add_wlus - Adds required W-LUs * @hba: per-adapter instance * * UFS device specification requires the UFS devices to support 4 well know= n * logical units: * "REPORT_LUNS" (address: 01h) * "UFS Device" (address: 50h) * "RPMB" (address: 44h) * "BOOT" (address: 30h) * UFS device's power management needs to be controlled by "POWER CONDITION= " * field of SSU (START STOP UNIT) command. But this "power condition" field * will take effect only when its sent to "UFS device" well known logical u= nit * hence we require the scsi_device instance to represent this logical unit= in * order for the UFS host driver to send the SSU command for power manageme= nt. * * We also require the scsi_device instance for "RPMB" (Replay Protected Me= mory * Block) LU so user space process can control this LU. User space may also * want to have access to BOOT LU. * * This function adds scsi device instances for each of all well known LUs * (except "REPORT LUNS" LU). * * Return: zero on success (all required W-LUs are added successfully), * non-zero error value on failure (if failed to add any of the required W-= LU). */ static int ufshcd_scsi_add_wlus(struct ufs_hba *hba) { int ret =3D 0; struct scsi_device *sdev_boot, *sdev_rpmb; hba->ufs_device_wlun =3D __scsi_add_device(hba->host, 0, 0, ufshcd_upiu_wlun_to_scsi_wlun(UFS_UPIU_UFS_DEVICE_WLUN), NULL); if (IS_ERR(hba->ufs_device_wlun)) { ret =3D PTR_ERR(hba->ufs_device_wlun); hba->ufs_device_wlun =3D NULL; goto out; } scsi_device_put(hba->ufs_device_wlun); sdev_rpmb =3D __scsi_add_device(hba->host, 0, 0, ufshcd_upiu_wlun_to_scsi_wlun(UFS_UPIU_RPMB_WLUN), NULL); if (IS_ERR(sdev_rpmb)) { ret =3D PTR_ERR(sdev_rpmb); goto remove_ufs_device_wlun; } ufshcd_blk_pm_runtime_init(sdev_rpmb); scsi_device_put(sdev_rpmb); sdev_boot =3D __scsi_add_device(hba->host, 0, 0, ufshcd_upiu_wlun_to_scsi_wlun(UFS_UPIU_BOOT_WLUN), NULL); if (IS_ERR(sdev_boot)) { dev_err(hba->dev, "%s: BOOT WLUN not found\n", __func__); } else { ufshcd_blk_pm_runtime_init(sdev_boot); scsi_device_put(sdev_boot); } goto out; remove_ufs_device_wlun: scsi_remove_device(hba->ufs_device_wlun); out: return ret; } ``` --------------------------------------------------------------------------- My question is: which approach would be more appropriate for using WLUN devices in UFS driver on FreeBSD? (1) Add support in SCSI XPT to probe WLUNs and allocate devices for them. (2) Follow Linux: have the UFS driver explicitly probe/register WLUN devices itself. If (2) is preferred, what is the recommended way for the UFSHCI driver to probe/register WLUNs in FreeBSD? (Is there an equivalent to Linux=E2=80=99s __scsi_add_device()?) Thanks, Jaeyoon