[PATCH] scsi: ufs: core: Clear power-on UNIT ATTENTION on BIWIN devices

[PATCH] scsi: ufs: core: Clear power-on UNIT ATTENTION on BIWIN devices

[Alexey Charkov]

With the link off across suspend (UFS_PM_LVL_5), resume resets the device,
which leaves a power-on UNIT ATTENTION pending on every logical unit. The
SCSI core retries the command that receives it and relies on the device to
clear the condition once reported.

The BIWIN BWU2A0526B128G and BWU2A0516B064G do not clear it when reporting
it to a WRITE. Writes queued across a system suspend then fail on every
retry for the full 180s retry window, until the SCSI error handler's
TEST UNIT READY clears it, and end in I/O errors. A single TEST UNIT READY
or READ clears it. This seems to be limited to the particular BIWIN device
family (with 128GB and 64GB variants exhibiting this behavior), as Samsung
and FORESEE ones I have tested clear it on WRITE as they should.

Add a device quirk that sends a TEST UNIT READY to each logical unit at
the end of ufshcd_host_reset_and_restore(), and enable it for BIWIN
models starting with BWU2A05. That function follows every device reset:
on resume from link off, system or runtime, and in the UFS error
handler, which also carries out the SCSI error handler's host resets.

Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
 drivers/ufs/core/ufshcd.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++
 include/ufs/ufs_quirks.h  |  9 ++++++++
 include/ufs/ufshcd.h      |  1 +
 3 files changed, 64 insertions(+)

diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index ee643830a57a..d52275a813fd 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -321,6 +321,9 @@ static const struct ufs_dev_quirk ufs_fixups[] = {
 	{ .wmanufacturerid = UFS_VENDOR_TOSHIBA,
 	  .model = "THGJFJT1E45BATP",
 	  .quirk = UFS_DEVICE_QUIRK_NO_TIMESTAMP_SUPPORT },
+	{ .wmanufacturerid = UFS_VENDOR_BIWIN,
+	  .model = "BWU2A05",
+	  .quirk = UFS_DEVICE_QUIRK_TUR_TO_CLEAR_UA },
 	{}
 };
 
@@ -8265,6 +8268,55 @@ static void ufshcd_process_probe_result(struct ufs_hba *hba,
 			  hba->curr_dev_pwr_mode, hba->uic_link_state);
 }
 
+/**
+ * ufshcd_clear_unit_attention - clear the power-on UNIT ATTENTION of each LU
+ * @hba: per adapter instance
+ *
+ * Send a TEST UNIT READY to each logical unit to clear the power-on UNIT
+ * ATTENTION left by a device reset, for devices that keep reporting it to
+ * WRITE commands instead. Receiving the UNIT ATTENTION is what clears it, so
+ * only transport failures matter.
+ *
+ * Use the device management slot rather than the logical units' request
+ * queues: those are blocked during error handling, and during a runtime
+ * resume of the device W-LU its runtime suspended consumers cannot take
+ * requests until it has resumed.
+ */
+static void ufshcd_clear_unit_attention(struct ufs_hba *hba)
+{
+	struct utp_upiu_req req_upiu, rsp_upiu;
+	struct scsi_device *sdev;
+	int err;
+
+	shost_for_each_device(sdev, hba->host) {
+		if (scsi_is_wlun(sdev->lun))
+			continue;
+
+		req_upiu = (struct utp_upiu_req){
+			.header = {
+				.transaction_code = UPIU_TRANSACTION_COMMAND,
+				.lun = ufshcd_scsi_to_upiu_lun(sdev->lun),
+				.command_set_type = UPIU_COMMAND_SET_TYPE_SCSI,
+			},
+			.sc.cdb[0] = TEST_UNIT_READY,
+		};
+
+		ufshcd_dev_man_lock(hba);
+		err = ufshcd_issue_devman_upiu_cmd(hba, &req_upiu, &rsp_upiu,
+						   NULL, NULL,
+						   DEV_CMD_TYPE_SCSI,
+						   UPIU_QUERY_OPCODE_NOP);
+		ufshcd_dev_man_unlock(hba);
+		if (err) {
+			dev_warn(hba->dev,
+				 "TEST UNIT READY to LUN %llu failed: %d\n",
+				 sdev->lun, err);
+			scsi_device_put(sdev);
+			break;
+		}
+	}
+}
+
 /**
  * ufshcd_host_reset_and_restore - reset and restore host controller
  * @hba: per-adapter instance
@@ -8306,6 +8358,8 @@ static int ufshcd_host_reset_and_restore(struct ufs_hba *hba)
 
 	if (err)
 		dev_err(hba->dev, "%s: Host init failed %d\n", __func__, err);
+	else if (hba->dev_quirks & UFS_DEVICE_QUIRK_TUR_TO_CLEAR_UA)
+		ufshcd_clear_unit_attention(hba);
 	ufshcd_update_evt_hist(hba, UFS_EVT_HOST_RESET, (u32)err);
 	return err;
 }
diff --git a/include/ufs/ufs_quirks.h b/include/ufs/ufs_quirks.h
index e9c59ec1ceae..74d4ca3badb7 100644
--- a/include/ufs/ufs_quirks.h
+++ b/include/ufs/ufs_quirks.h
@@ -17,6 +17,7 @@
 #define UFS_VENDOR_SKHYNIX     0x1AD
 #define UFS_VENDOR_TOSHIBA     0x198
 #define UFS_VENDOR_WDC         0x145
+#define UFS_VENDOR_BIWIN       0xDAB
 
 /**
  * ufs_dev_quirk - ufs device quirk info
@@ -109,4 +110,12 @@ struct ufs_dev_quirk {
 /* Some UFS 4 devices do not support the qTimestamp attribute */
 #define UFS_DEVICE_QUIRK_NO_TIMESTAMP_SUPPORT	(1 << 13)
 
+/*
+ * Some UFS devices do not clear the power-on UNIT ATTENTION condition when
+ * reporting it to a WRITE command, so writes keep failing with it. A TEST
+ * UNIT READY clears it. Enable this quirk to send one to each logical unit
+ * after every host reset and restore, which follows each device reset.
+ */
+#define UFS_DEVICE_QUIRK_TUR_TO_CLEAR_UA	(1 << 14)
+
 #endif /* UFS_QUIRKS_H_ */
diff --git a/include/ufs/ufshcd.h b/include/ufs/ufshcd.h
index be62165b785e..6140798ed128 100644
--- a/include/ufs/ufshcd.h
+++ b/include/ufs/ufshcd.h
@@ -37,6 +37,7 @@ enum dev_cmd_type {
 	DEV_CMD_TYPE_NOP		= 0x0,
 	DEV_CMD_TYPE_QUERY		= 0x1,
 	DEV_CMD_TYPE_RPMB		= 0x2,
+	DEV_CMD_TYPE_SCSI		= 0x3,
 };
 
 enum ufs_event_type {

---
base-commit: 151a134a4e6ec66f69db8750c66006f5207f7a9d
change-id: 20261028-biwin-tua-quirk-4f543fc96116

Best regards,
--  
Alexey Charkov <alchark@flipper.net>

Re: [PATCH] scsi: ufs: core: Clear power-on UNIT ATTENTION on BIWIN devices

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] scsi: ufs: unhandled broken OCS quirk in ufshcd_clear_unit_attention()
- [Medium] scsi: ufs: core: ufshcd_issue_devman_upiu_cmd() hardcodes lun 0 in lrbp
--

commit 02e1f4aa450245801c780ec99fe1072a3f8e77c3
Author: Alexey Charkov <alchark@flipper.net>

scsi: ufs: core: Clear power-on UNIT ATTENTION on BIWIN devices

This patch adds a device quirk for BIWIN UFS devices (models starting with
BWU2A05) to clear pending power-on unit attention conditions across all
logical units after a host reset and restore by issuing a TEST_UNIT_READY
command via the device management slot.

> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> index ee643830a57a2..d52275a813fd3 100644
> --- a/drivers/ufs/core/ufshcd.c
> +++ b/drivers/ufs/core/ufshcd.c

[ ... ]

> @@ -8265,6 +8268,55 @@ static void ufshcd_process_probe_result(struct ufs_hba *hba,
>  			  hba->curr_dev_pwr_mode, hba->uic_link_state);
>  }
>  
> +/**
> + * ufshcd_clear_unit_attention - clear the power-on UNIT ATTENTION of each LU
> + * @hba: per adapter instance
> + *
> + * Send a TEST UNIT READY to each logical unit to clear the power-on UNIT
> + * ATTENTION left by a device reset, for devices that keep reporting it to
> + * WRITE commands instead. Receiving the UNIT ATTENTION is what clears it, so
> + * only transport failures matter.
> + *
> + * Use the device management slot rather than the logical units' request
> + * queues: those are blocked during error handling, and during a runtime
> + * resume of the device W-LU its runtime suspended consumers cannot take
> + * requests until it has resumed.
> + */
> +static void ufshcd_clear_unit_attention(struct ufs_hba *hba)
> +{
> +	struct utp_upiu_req req_upiu, rsp_upiu;
> +	struct scsi_device *sdev;
> +	int err;
> +
> +	shost_for_each_device(sdev, hba->host) {
> +		if (scsi_is_wlun(sdev->lun))
> +			continue;
> +
> +		req_upiu = (struct utp_upiu_req){
> +			.header = {
> +				.transaction_code = UPIU_TRANSACTION_COMMAND,
> +				.lun = ufshcd_scsi_to_upiu_lun(sdev->lun),
> +				.command_set_type = UPIU_COMMAND_SET_TYPE_SCSI,
> +			},
> +			.sc.cdb[0] = TEST_UNIT_READY,
> +		};
> +
> +		ufshcd_dev_man_lock(hba);
> +		err = ufshcd_issue_devman_upiu_cmd(hba, &req_upiu, &rsp_upiu,
> +						   NULL, NULL,
> +						   DEV_CMD_TYPE_SCSI,
> +						   UPIU_QUERY_OPCODE_NOP);

[Severity: Medium]
When ufshcd_clear_unit_attention() sends a DEV_CMD_TYPE_SCSI command to a
non-zero LUN, ufshcd_issue_devman_upiu_cmd() still passes a hardcoded LUN of
0 to ufshcd_setup_dev_cmd():

drivers/ufs/core/ufshcd.c:ufshcd_issue_devman_upiu_cmd() {
	...
	tag = scsi_cmd_to_rq(cmd)->tag;

	ufshcd_setup_dev_cmd(hba, cmd, cmd_type, 0, tag);
	...
}

This leaves lrbp->lun set to 0 even though req_upiu.header.lun targets a
non-zero LUN.

If the command times out during error recovery (for example via
ufshcd_err_handler() -> ufshcd_reset_and_restore() ->
ufshcd_host_reset_and_restore() -> ufshcd_clear_unit_attention() when
hba->pm_op_in_progress is false), scmd_eh_abort_handler() invokes
ufshcd_abort() -> ufshcd_mcq_abort() -> ufshcd_try_to_abort_task(), which
uses lrbp->lun to issue UFS_QUERY_TASK and UFS_ABORT_TASK:

drivers/ufs/core/ufshcd.c:ufshcd_try_to_abort_task() {
	...
	for (poll_cnt = 100; poll_cnt; poll_cnt--) {
		err = ufshcd_issue_tm_cmd(hba, lrbp->lun, tag, UFS_QUERY_TASK,
					  &resp);
	...
}

And ufshcd_clear_cmd() -> ufshcd_mcq_sq_cleanup() also uses lrbp->lun to
build the nexus written to REG_SQCTI:

drivers/ufs/core/ufs-mcq.c:ufshcd_mcq_sq_cleanup() {
	...
	/* SQCTI = EXT_IID, IID, LUN, Task Tag */
	nexus = lrbp->lun << 8 | task_tag;
	opr_sqd_base = mcq_opr_base(hba, OPR_SQD, id);
	writel(nexus, opr_sqd_base + REG_SQCTI);
	...
}

Should ufshcd_issue_devman_upiu_cmd() pass req_upiu->header.lun instead of 0
to ufshcd_setup_dev_cmd() so that task abort and MCQ queue cleanup target the
right LUN?

> +		ufshcd_dev_man_unlock(hba);
> +		if (err) {
> +			dev_warn(hba->dev,
> +				 "TEST UNIT READY to LUN %llu failed: %d\n",
> +				 sdev->lun, err);
> +			scsi_device_put(sdev);
> +			break;
> +		}

[Severity: Medium]
What happens here on host controllers with UFSHCD_QUIRK_BROKEN_OCS_FATAL_ERROR
(such as ufs-exynos)?

When a logical unit has a pending unit attention condition, the device
responds to TEST_UNIT_READY with a Response UPIU having header.response set
to TARGET_FAILURE and header.status set to SAM_STAT_CHECK_CONDITION. On
controllers with UFSHCD_QUIRK_BROKEN_OCS_FATAL_ERROR, hardware reports
OCS_FATAL_ERROR in the UTRD/CQE whenever the Response UPIU has a non-zero
response or status field.

For normal SCSI commands, ufshcd_transfer_rsp_status() overrides ocs back to
OCS_SUCCESS:

drivers/ufs/core/ufshcd.c:ufshcd_transfer_rsp_status() {
	...
	if (hba->quirks & UFSHCD_QUIRK_BROKEN_OCS_FATAL_ERROR) {
		if (lrbp->ucd_rsp_ptr->header.response ||
		    lrbp->ucd_rsp_ptr->header.status)
			ocs = OCS_SUCCESS;
	}
	...
}

However, ufshcd_issue_devman_upiu_cmd() uses a reserved device management
command (!ufshcd_is_scsi_cmd(cmd)). In ufshcd_compl_one_cqe(), the reserved
command path bypasses ufshcd_transfer_rsp_status() and leaves
lrbp->utr_descriptor_ptr->header.ocs as OCS_FATAL_ERROR, which
ufshcd_issue_dev_cmd() then returns directly:

drivers/ufs/core/ufshcd.c:ufshcd_issue_dev_cmd() {
	...
	rq->timeout = timeout;
	sts = blk_execute_rq(rq, true);
	if (sts != BLK_STS_OK)
		return blk_status_to_errno(sts);
	return lrbp->utr_descriptor_ptr->header.ocs;
}

Wouldn't this cause ufshcd_clear_unit_attention() to see OCS_FATAL_ERROR on
the first LUN that reports unit attention, log a warning, and break out of
the loop before clearing the remaining LUNs?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261028-biwin-tua-quirk-v1-1-767a12c9b9cc@flipper.net?part=1

Re: [PATCH] scsi: ufs: core: Clear power-on UNIT ATTENTION on BIWIN devices

[Alexey Charkov]

On Wed, Oct 28, 2026 at 5:17 PM <sashiko-bot@kernel.org> wrote:
>
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [Medium] scsi: ufs: unhandled broken OCS quirk in ufshcd_clear_unit_attention()
> - [Medium] scsi: ufs: core: ufshcd_issue_devman_upiu_cmd() hardcodes lun 0 in lrbp
> --
>
> commit 02e1f4aa450245801c780ec99fe1072a3f8e77c3
> Author: Alexey Charkov <alchark@flipper.net>
>
> scsi: ufs: core: Clear power-on UNIT ATTENTION on BIWIN devices
>
> This patch adds a device quirk for BIWIN UFS devices (models starting with
> BWU2A05) to clear pending power-on unit attention conditions across all
> logical units after a host reset and restore by issuing a TEST_UNIT_READY
> command via the device management slot.
>
> > diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> > index ee643830a57a2..d52275a813fd3 100644
> > --- a/drivers/ufs/core/ufshcd.c
> > +++ b/drivers/ufs/core/ufshcd.c
>
> [ ... ]
>
> > @@ -8265,6 +8268,55 @@ static void ufshcd_process_probe_result(struct ufs_hba *hba,
> >                         hba->curr_dev_pwr_mode, hba->uic_link_state);
> >  }
> >
> > +/**
> > + * ufshcd_clear_unit_attention - clear the power-on UNIT ATTENTION of each LU
> > + * @hba: per adapter instance
> > + *
> > + * Send a TEST UNIT READY to each logical unit to clear the power-on UNIT
> > + * ATTENTION left by a device reset, for devices that keep reporting it to
> > + * WRITE commands instead. Receiving the UNIT ATTENTION is what clears it, so
> > + * only transport failures matter.
> > + *
> > + * Use the device management slot rather than the logical units' request
> > + * queues: those are blocked during error handling, and during a runtime
> > + * resume of the device W-LU its runtime suspended consumers cannot take
> > + * requests until it has resumed.
> > + */
> > +static void ufshcd_clear_unit_attention(struct ufs_hba *hba)
> > +{
> > +     struct utp_upiu_req req_upiu, rsp_upiu;
> > +     struct scsi_device *sdev;
> > +     int err;
> > +
> > +     shost_for_each_device(sdev, hba->host) {
> > +             if (scsi_is_wlun(sdev->lun))
> > +                     continue;
> > +
> > +             req_upiu = (struct utp_upiu_req){
> > +                     .header = {
> > +                             .transaction_code = UPIU_TRANSACTION_COMMAND,
> > +                             .lun = ufshcd_scsi_to_upiu_lun(sdev->lun),
> > +                             .command_set_type = UPIU_COMMAND_SET_TYPE_SCSI,
> > +                     },
> > +                     .sc.cdb[0] = TEST_UNIT_READY,
> > +             };
> > +
> > +             ufshcd_dev_man_lock(hba);
> > +             err = ufshcd_issue_devman_upiu_cmd(hba, &req_upiu, &rsp_upiu,
> > +                                                NULL, NULL,
> > +                                                DEV_CMD_TYPE_SCSI,
> > +                                                UPIU_QUERY_OPCODE_NOP);
>
> [Severity: Medium]
> When ufshcd_clear_unit_attention() sends a DEV_CMD_TYPE_SCSI command to a
> non-zero LUN, ufshcd_issue_devman_upiu_cmd() still passes a hardcoded LUN of
> 0 to ufshcd_setup_dev_cmd():
>
> drivers/ufs/core/ufshcd.c:ufshcd_issue_devman_upiu_cmd() {
>         ...
>         tag = scsi_cmd_to_rq(cmd)->tag;
>
>         ufshcd_setup_dev_cmd(hba, cmd, cmd_type, 0, tag);
>         ...
> }
>
> This leaves lrbp->lun set to 0 even though req_upiu.header.lun targets a
> non-zero LUN.
>
> If the command times out during error recovery (for example via
> ufshcd_err_handler() -> ufshcd_reset_and_restore() ->
> ufshcd_host_reset_and_restore() -> ufshcd_clear_unit_attention() when
> hba->pm_op_in_progress is false), scmd_eh_abort_handler() invokes
> ufshcd_abort() -> ufshcd_mcq_abort() -> ufshcd_try_to_abort_task(), which
> uses lrbp->lun to issue UFS_QUERY_TASK and UFS_ABORT_TASK:
>
> drivers/ufs/core/ufshcd.c:ufshcd_try_to_abort_task() {
>         ...
>         for (poll_cnt = 100; poll_cnt; poll_cnt--) {
>                 err = ufshcd_issue_tm_cmd(hba, lrbp->lun, tag, UFS_QUERY_TASK,
>                                           &resp);
>         ...
> }
>
> And ufshcd_clear_cmd() -> ufshcd_mcq_sq_cleanup() also uses lrbp->lun to
> build the nexus written to REG_SQCTI:
>
> drivers/ufs/core/ufs-mcq.c:ufshcd_mcq_sq_cleanup() {
>         ...
>         /* SQCTI = EXT_IID, IID, LUN, Task Tag */
>         nexus = lrbp->lun << 8 | task_tag;
>         opr_sqd_base = mcq_opr_base(hba, OPR_SQD, id);
>         writel(nexus, opr_sqd_base + REG_SQCTI);
>         ...
> }
>
> Should ufshcd_issue_devman_upiu_cmd() pass req_upiu->header.lun instead of 0
> to ufshcd_setup_dev_cmd() so that task abort and MCQ queue cleanup target the
> right LUN?

Makes sense, I'll implement this in v2 after waiting for other feedback.

> > +             ufshcd_dev_man_unlock(hba);
> > +             if (err) {
> > +                     dev_warn(hba->dev,
> > +                              "TEST UNIT READY to LUN %llu failed: %d\n",
> > +                              sdev->lun, err);
> > +                     scsi_device_put(sdev);
> > +                     break;
> > +             }
>
> [Severity: Medium]
> What happens here on host controllers with UFSHCD_QUIRK_BROKEN_OCS_FATAL_ERROR
> (such as ufs-exynos)?
>
> When a logical unit has a pending unit attention condition, the device
> responds to TEST_UNIT_READY with a Response UPIU having header.response set
> to TARGET_FAILURE and header.status set to SAM_STAT_CHECK_CONDITION. On
> controllers with UFSHCD_QUIRK_BROKEN_OCS_FATAL_ERROR, hardware reports
> OCS_FATAL_ERROR in the UTRD/CQE whenever the Response UPIU has a non-zero
> response or status field.
>
> For normal SCSI commands, ufshcd_transfer_rsp_status() overrides ocs back to
> OCS_SUCCESS:
>
> drivers/ufs/core/ufshcd.c:ufshcd_transfer_rsp_status() {
>         ...
>         if (hba->quirks & UFSHCD_QUIRK_BROKEN_OCS_FATAL_ERROR) {
>                 if (lrbp->ucd_rsp_ptr->header.response ||
>                     lrbp->ucd_rsp_ptr->header.status)
>                         ocs = OCS_SUCCESS;
>         }
>         ...
> }
>
> However, ufshcd_issue_devman_upiu_cmd() uses a reserved device management
> command (!ufshcd_is_scsi_cmd(cmd)). In ufshcd_compl_one_cqe(), the reserved
> command path bypasses ufshcd_transfer_rsp_status() and leaves
> lrbp->utr_descriptor_ptr->header.ocs as OCS_FATAL_ERROR, which
> ufshcd_issue_dev_cmd() then returns directly:
>
> drivers/ufs/core/ufshcd.c:ufshcd_issue_dev_cmd() {
>         ...
>         rq->timeout = timeout;
>         sts = blk_execute_rq(rq, true);
>         if (sts != BLK_STS_OK)
>                 return blk_status_to_errno(sts);
>         return lrbp->utr_descriptor_ptr->header.ocs;
> }
>
> Wouldn't this cause ufshcd_clear_unit_attention() to see OCS_FATAL_ERROR on
> the first LUN that reports unit attention, log a warning, and break out of
> the loop before clearing the remaining LUNs?

It probably will, but this failure mode requires a BIWIN
BWU2A05-series UFS device on an Exynos host controller, which is not a
combination I have access to (I only have Rockchip RK3576 boards). I'm
not sure those even exist.

If anything, this should probably be fixed in the common
ufshcd_compl_one_cqe() function, not directly related to this patch,
because it would also affect similar pre-existing logic in the
Advanced RPMB flow.

Best regards,
Alexey

Re: [PATCH] scsi: ufs: core: Clear power-on UNIT ATTENTION on BIWIN devices

[Bart Van Assche]

On 10/28/26 5:54 AM, Alexey Charkov wrote:
>   drivers/ufs/core/ufshcd.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++
>   include/ufs/ufs_quirks.h  |  9 ++++++++
>   include/ufs/ufshcd.h      |  1 +

The quirk has been implemented in the wrong layer. The right layer to
implement this type of quirk is the SCSI disk driver (sd.c).

Bart.

Re: [PATCH] scsi: ufs: core: Clear power-on UNIT ATTENTION on BIWIN devices

[Alexey Charkov]

On Wed, Oct 28, 2026 at 10:40 PM Bart Van Assche <bvanassche@acm.org> wrote:
>
> On 10/28/26 5:54 AM, Alexey Charkov wrote:
> >   drivers/ufs/core/ufshcd.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++
> >   include/ufs/ufs_quirks.h  |  9 ++++++++
> >   include/ufs/ufshcd.h      |  1 +
>
> The quirk has been implemented in the wrong layer. The right layer to
> implement this type of quirk is the SCSI disk driver (sd.c).

Thanks, Bart. I'll see how to redo it at that layer and send a v2.

Best regards,
Alexey