From nobody Sun Sep 28 21:48:06 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 4cZdH928Ppz68LKS for ; Sun, 28 Sep 2025 21:48:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cZdH83XJMz3NYg for ; Sun, 28 Sep 2025 21:48:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20230601.gappssmtp.com header.s=20230601 header.b=W5apSTPb; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::1029) smtp.mailfrom=wlosh@bsdimp.com Received: by mail-pj1-x1029.google.com with SMTP id 98e67ed59e1d1-330b0bb4507so3341617a91.3 for ; Sun, 28 Sep 2025 14:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1759096098; x=1759700898; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=PIDgMiVTKg8lkiP276Ss2TKONfbw1ffmWfvjmn/QCzQ=; b=W5apSTPb1eQO7ziGaHdULvHjZe4YBy1gDP+cbOayX+riygyY4mqvY6uGGAKmT9p4Zi dotZIWXyl3CYULnsnjSi/GkH18t+S9WyA5+Q8YM3Qd2FYlNpTC/ldDIHq64fu5uLEgEp /wvzGz2zd5mlXjUT1YRRqQ+qsgXN08SiXXqfrVfWpzj89LjJVLCyhWOoxRJdzfSIwX1M wI7QpWpJN+HTw6EeTj9d9CMBKjybTAm1DH7Q9gkfJm6T9t7/nzE5tUj556gTNAhlyLRH UoZQqimphvYSYYPV8S664hOJ+FKYdVrx9pYJ+SVaQoaAuw6KkObW7iBoCFXYARcOnMLu nIKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759096098; x=1759700898; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=PIDgMiVTKg8lkiP276Ss2TKONfbw1ffmWfvjmn/QCzQ=; b=UGOTyIabLSvU1DRMUgA2QVvugy9HREK/k2M3T0CTWBHB3jjRTxCNqtHv7+YDpG02a+ LzgIv3w6GGOlp/YiHimK7wo361l6Lzc2HdgwSGzCnnEbQ3KROQgwiJo5BB8cHMxUTKWO 86DHkQHpg3+l4jn29nLWxJsqTGoNU6vMWS6b7GIUCjMZtn9j9WnZBImSwJ3FEbp31Qx0 HQ9vmdAPdvKhf3dYhIgJTrBLHzrID6JZmbfPUVCsx68hP4xBjeIUi9qwFyGDJFl/KRbs X8M8p0rsSFwPtQ72eBTEliOur4SYYk/+bvNL8HGJ9sg35t3SFKU3zwYfkn17pGb0Mfip IniA== X-Gm-Message-State: AOJu0Yxo1I571P1agENyw7Ifv+1Czqe4gjc3C76aiKYfWKaqSiHRKuWo fpS8EvQk1/jQmpcs1fkvPO3l1heczuICBYhO5TQ9LxX2HyzrBUmeIfsLC9d0vs2zvCv+Y5yikbG xGxtqzgBDS8Q2/wv3HjWSmJDVPK22shzxKII9Xu2iexR5O2kMg7Syh2M= X-Gm-Gg: ASbGnctex+8qzPMMTtww4RsCo/W3b+dftAI+jM5KWboA0Vf0SwIuNu7tAci7joSNve7 S6ip4yNDMs6NSrEtlYLGV5Ebg04tDc0kPPSAicLxzPapHZDEKGb7JqPplTJbXCBI2rPvdnPluZ6 i62sv6CMBPmuhOQ1iVi7/J96niHDPVErid7A4WxM318X6Vh/ZiPzvR0oyyJJziJ9vM9KPrA+J/W SWpmk8= X-Google-Smtp-Source: AGHT+IE1Ol8t/Ww6UHOw1xg9S3kWZQnCaxs0Nw/QvDryJ70uuAk5lXi3aUXQe8WJxYaxiQ6QUZHQ14zWX6TEhMfWUAo= X-Received: by 2002:a17:90b:1c8e:b0:330:6d2f:1b5d with SMTP id 98e67ed59e1d1-3342a2e3a0amr14973666a91.26.1759096097779; Sun, 28 Sep 2025 14:48:17 -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 References: In-Reply-To: From: Warner Losh Date: Sun, 28 Sep 2025 15:48:06 -0600 X-Gm-Features: AS18NWDgimZZGj5Zf0R5Ei2cdUdI-XD1DIlaIf8akRm3XoZ1dHjeJuLhEoB7Lto Message-ID: Subject: Re: Questions about probing WLUNs for UFS power management To: Jaeyoon Choi Cc: freebsd-scsi@freebsd.org Content-Type: multipart/alternative; boundary="00000000000008c5ad063fe37abc" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.989]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20230601.gappssmtp.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MISSING_XM_UA(0.00)[]; R_SPF_NA(0.00)[no SPF record]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1029:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-scsi@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-scsi@freebsd.org]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+] X-Rspamd-Queue-Id: 4cZdH83XJMz3NYg --00000000000008c5ad063fe37abc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Please excuse the tardy response On Tue, Sep 23, 2025 at 8:32=E2=80=AFPM Jaeyoon Choi = wrote: > Hello freebsd-scsi, > > I=E2=80=99m trying to implement Well-known LUNs (WLUNs) for the UFS (Univ= ersal > 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 logica= l > 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 > known > * 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" fie= ld > * will take effect only when its sent to "UFS device" well known logical > unit > * 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 > management. > * > * We also require the scsi_device instance for "RPMB" (Replay Protected > Memory > * Block) LU so user space process can control this LU. User space may al= so > * want to have access to BOOT LU. > * > * This function adds scsi device instances for each of all well known LU= s > * (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()?) > [[ I didn't trim context here, since it lays out the problem nicely). ]] So I can make a case for either (1) or (2). It's easy enough to add the enumeration for (1) to scsi_xpt.c It's just a few more states in the probe state machine (which is a bit complex, but not terribly so). If we treat them as separate LUNs, then a lot of the infrastructure would just work. The key, though, is how do we keep scsi_da, etc from attaching to these new nodes. And would we have generic scsi_foo.c drivers for them (so the devices would get their own periph drivers) or whether there's a higher-level device that would know it could use these devices if it finds them and it wouldn't have a specific specialized kernel drive for them, but instead use a generalized pass thru device. I guess a lot of that would depend where things like power management is happening. If it's in the UFS sim, that would suggest a different design than if this was some super generic thing that would respond to generic events that maybe the SIMs generate or maybe somebody else. If we wanted to go with (1) heavily, we'd need new, generic periph drivers along with some kind of way to get them to respond to, or report out events in the system or with the drive. With only a couple of examples, this might be difficult to abstract properly. If we wanted to go with (2), then we'd likely need some extensions in xpt around this so that the sim could discover, manage and use the WLUN devices= . Though the more I think about it, maybe it doesn't matter: we want to do the WLUN probing regardless. It's who manages the cam_ed structures after that. Where does the periph driver live, etc. I think I need to go read the UFS specs in more detail than I have time for this afternoon... Warner Warner --00000000000008c5ad063fe37abc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Please excuse the tardy response
On Tue, Sep 23, 2025 at 8:32=E2=80=AFPM Jaeyoon Choi <jaeyoon@freebsd.org> wrote:
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 prob= e
WLUNs, so I have a few questions.

First, Well-known LUNs are defined in SCSI SAM-5. In UFS, 'REPORT LUNS&= #39;,
'UFS Device', 'RPMB', and 'BOOT' LUNs are treated a= s 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&quo= t;)

Because a UFS device contains multiple LUNs, power management requires
sending a START STOP UNIT(SSU) command to the 'UFS Device' WLUN. (I= f 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")<= br>
In FreeBSD, the SCSI XPT logic that parses LUNs checks the 'Simple logi= cal
unit addressing format' (SAM-5 Table 26) and the 8-byte 'Extended l= ogical
unit addressing format' (SAM-5 Table 35), but it does not check the
'Well-known logical unit extended addressing format' (SAM-5 Table 3= 7).
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)
...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 while (scan_info->lunindex[tar= get_id] < nluns) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (scan_info->c= pi->hba_misc & PIM_EXTLUNS) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CAM_G= ET_LUN(target->luns,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 scan_info->lunindex[target_id],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 lun_id);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 break= ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (CAM_CAN_GET_SIM= PLE_LUN(target->luns,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 scan_= info->lunindex[target_id])) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CAM_G= ET_SIMPLE_LUN(target->luns,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 scan_info->lunindex[target_id],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 lun_id);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 break= ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 scan_info->lunin= dex[target_id]++;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
```

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 Value= s")

```
sys/cam/scsi/scsi_xpt.c line:827
static void
probestart(struct cam_periph *periph, union ccb *start_ccb)
...
=C2=A0 =C2=A0 case PROBE_REPORT_LUNS:
...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 scsi_report_luns(csio, 5, probedone, MSG_SIMPLE= _Q_TAG,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RPL_REPORT_DEFAULT, rp, periph-&g= t;path->target->rpl_size,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SSD_FULL_SIZE, 60000);
```
```
sys/cam/scsi/scsi_all.h line:3020
struct scsi_report_luns
{
=C2=A0 =C2=A0 uint8_t opcode;
=C2=A0 =C2=A0 uint8_t reserved1;
#define RPL_REPORT_DEFAULT=C2=A0 =C2=A0 =C2=A00x00
#define RPL_REPORT_WELLKNOWN=C2=A0 =C2=A00x01
```

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
/**
=C2=A0* ufshcd_scsi_add_wlus - Adds required W-LUs
=C2=A0* @hba: per-adapter instance
=C2=A0*
=C2=A0* UFS device specification requires the UFS devices to support 4 well= known
=C2=A0* logical units:
=C2=A0*=C2=A0 "REPORT_LUNS" (address: 01h)
=C2=A0*=C2=A0 "UFS Device" (address: 50h)
=C2=A0*=C2=A0 "RPMB" (address: 44h)
=C2=A0*=C2=A0 "BOOT" (address: 30h)
=C2=A0* UFS device's power management needs to be controlled by "P= OWER CONDITION"
=C2=A0* field of SSU (START STOP UNIT) command. But this "power condit= ion" field
=C2=A0* will take effect only when its sent to "UFS device" well = known logical unit
=C2=A0* hence we require the scsi_device instance to represent this logical= unit in
=C2=A0* order for the UFS host driver to send the SSU command for power man= agement.
=C2=A0*
=C2=A0* We also require the scsi_device instance for "RPMB" (Repl= ay Protected Memory
=C2=A0* Block) LU so user space process can control this LU. User space may= also
=C2=A0* want to have access to BOOT LU.
=C2=A0*
=C2=A0* This function adds scsi device instances for each of all well known= LUs
=C2=A0* (except "REPORT LUNS" LU).
=C2=A0*
=C2=A0* Return: zero on success (all required W-LUs are added successfully)= ,
=C2=A0* non-zero error value on failure (if failed to add any of the requir= ed W-LU).
=C2=A0*/
static int ufshcd_scsi_add_wlus(struct ufs_hba *hba)
{
=C2=A0 =C2=A0 int ret =3D 0;
=C2=A0 =C2=A0 struct scsi_device *sdev_boot, *sdev_rpmb;

=C2=A0 =C2=A0 hba->ufs_device_wlun =3D __scsi_add_device(hba->host, 0= , 0,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ufshcd_upiu_wlun_to_scsi_wlun(UFS_UPIU_UFS_DEVI= CE_WLUN), NULL);
=C2=A0 =C2=A0 if (IS_ERR(hba->ufs_device_wlun)) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ret =3D PTR_ERR(hba->ufs_device_wlun);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 hba->ufs_device_wlun =3D NULL;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 goto out;
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 scsi_device_put(hba->ufs_device_wlun);

=C2=A0 =C2=A0 sdev_rpmb =3D __scsi_add_device(hba->host, 0, 0,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ufshcd_upiu_wlun_to_scsi_wlun(UFS_UPIU_RPMB_WLU= N), NULL);
=C2=A0 =C2=A0 if (IS_ERR(sdev_rpmb)) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ret =3D PTR_ERR(sdev_rpmb);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 goto remove_ufs_device_wlun;
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 ufshcd_blk_pm_runtime_init(sdev_rpmb);
=C2=A0 =C2=A0 scsi_device_put(sdev_rpmb);

=C2=A0 =C2=A0 sdev_boot =3D __scsi_add_device(hba->host, 0, 0,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ufshcd_upiu_wlun_to_scsi_wlun(UFS_UPIU_BOOT_WLU= N), NULL);
=C2=A0 =C2=A0 if (IS_ERR(sdev_boot)) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 dev_err(hba->dev, "%s: BOOT WLUN not fo= und\n", __func__);
=C2=A0 =C2=A0 } else {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ufshcd_blk_pm_runtime_init(sdev_boot);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 scsi_device_put(sdev_boot);
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 goto out;

remove_ufs_device_wlun:
=C2=A0 =C2=A0 scsi_remove_device(hba->ufs_device_wlun);
out:
=C2=A0 =C2=A0 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
=C2=A0 =C2=A0 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()?)

[[ I didn't t= rim context here, since it lays out the problem nicely). ]]

<= /div>
So I can make a case for either (1) or (2).

<= div>It's easy enough to add the enumeration for (1) to scsi_xpt.c It= 9;s just a few more states in the probe state machine (which is a bit compl= ex, but not terribly so). If we treat them as separate LUNs, then a lot of = the infrastructure would just work. The key, though, is how do we keep scsi= _da, etc from attaching to these new nodes. And would we have generic scsi_= foo.c drivers for them (so the devices would get their own periph drivers) = or whether there's a higher-level device that would know it could use t= hese devices if it finds them and it wouldn't have a specific specializ= ed kernel drive for them, but instead use a generalized pass thru device.

I guess a lot of that would depend where things lik= e power management is happening. If it's in the UFS sim, that would sug= gest a different design than if this was some super generic thing that woul= d respond to generic events that maybe the SIMs generate or maybe somebody = else.

If we wanted to go with (1) heavily, we'= d need new, generic periph drivers along with some kind of way to get them = to respond to, or report out events in the system or with the drive. With o= nly a couple of examples, this might be difficult to abstract properly.

If we wanted to go with (2), then we'd likely nee= d some extensions in xpt around this so that the sim could discover, manage= and use the WLUN devices.

Though the more I think= about it, maybe it doesn't matter: we want to do the WLUN probing rega= rdless. It's who manages the cam_ed structures after that. Where does t= he periph driver live, etc.

I think I need to go r= ead the UFS specs in more detail than I have time for this afternoon...

Warner

Warner
--00000000000008c5ad063fe37abc--