[PATCH 0/2] scsi: support spinup notification for SAS SSP devices in Active_Wait/Idle_Wait state

[PATCH 0/2] scsi: support spinup notification for SAS SSP devices in Active_Wait/Idle_Wait state

[Xingui Yang]

When a SAS HDD connected via SSP (Serial Attached SCSI Protocol) is powered
up with the RNOT (Ready Not Optimized) bit set, the device enters the
Active_Wait or Idle_Wait power state per the SAS protocol specification. In
this state, the device does not respond to standard SCSI START_STOP spinup
commands and instead returns NOT_READY with ASC/ASCQ = 0x04/0x11 ("Logical
unit not ready, notify (enable spinup) required").

Without handling this condition, the SCSI mid-layer will indefinitely retry
the command with ACTION_DELAYED_RETRY, resulting in the disk never spinning
up and becoming unusable. A typical manifestation is:

  sd 4:0:9:0: [sde] Spinning up disk...
  ...not responding...
  sd 4:0:9:0: [sde] Sense Key : Not Ready
  sd 4:0:9:0: [sde] Add. Sense: Logical unit not ready, notify (enable spinup) required

To resolve this, the SAS controller needs to send a NOTIFY(ENABLE SPINUP)
primitive to the target phy, which transitions the device out of the waiting
state and allows normal spinup to proceed.

This patch series addresses the issue:

Adds a new optional spinup_notify callback to struct scsi_host_template
in the SCSI mid-layer. When ASC/ASCQ = 0x04/0x11 is detected in
scsi_io_completion_action(), the callback is invoked before the mid-layer
falls through to ACTION_DELAYED_RETRY, giving the LLDD an opportunity to
perform controller-specific spinup notification.

Xingui Yang (2):
  scsi: scsi_lib: add spinup_notify callback for ASC/ASCQ=0x04/0x11
  scsi: hisi_sas: add spinup_notify callback to handle
    Active_Wait/Idle_Wait SSP devices

 drivers/scsi/hisi_sas/hisi_sas.h       |  1 +
 drivers/scsi/hisi_sas/hisi_sas_main.c  | 25 +++++++++++++++++++++++++
 drivers/scsi/hisi_sas/hisi_sas_v1_hw.c |  1 +
 drivers/scsi/hisi_sas/hisi_sas_v2_hw.c |  1 +
 drivers/scsi/hisi_sas/hisi_sas_v3_hw.c |  1 +
 drivers/scsi/scsi_lib.c                |  4 ++++
 include/scsi/scsi_host.h               |  9 +++++++++
 7 files changed, 42 insertions(+)

-- 
2.43.0

[PATCH 1/2] scsi: scsi_lib: add spinup_notify callback for ASC/ASCQ=0x04/0x11

[Xingui Yang]

When a SCSI device returns NOT_READY with ASC/ASCQ = 0x04/0x11
("notify (enable spinup) required"), the device is in Active_Wait or
Idle_Wait power state and will not respond to standard START_STOP
spinup commands.

Add an optional spinup_notify callback to struct scsi_host_template.
When ASCQ=0x11 is detected in the mid-layer, invoke this callback
before ACTION_DELAYED_RETRY, allowing LLDDs to perform controller-
specific spinup notification.

Example log:
[Tue Jun 23 08:34:44 2026] sd 4:0:9:0: [sde] Spinning up disk...
[Tue Jun 23 08:36:22 2026] ...not responding...
[Tue Jun 23 08:36:24 2026] sd 4:0:9:0: [sde] Sense Key : Not Ready
[Tue Jun 23 08:36:24 2026] sd 4:0:9:0: [sde] Add. Sense: Logical unit
  not ready, notify (enable spinup) required

Signed-off-by: Xingui Yang <yangxingui@huawei.com>
---
 drivers/scsi/scsi_lib.c  | 4 ++++
 include/scsi/scsi_host.h | 9 +++++++++
 2 files changed, 13 insertions(+)

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index b67f0dc79499..33c4339ca8c5 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -905,6 +905,10 @@ static void scsi_io_completion_action(struct scsi_cmnd *cmd, int result)
 				case 0x1a: /* start stop unit in progress */
 				case 0x1b: /* sanitize in progress */
 				case 0x1d: /* configuration in progress */
+					if (sshdr.ascq == 0x11 &&
+					    cmd->device->host->hostt->spinup_notify)
+						cmd->device->host->hostt->spinup_notify(
+							cmd->device);
 					action = ACTION_DELAYED_RETRY;
 					break;
 				case 0x0a: /* ALUA state transition */
diff --git a/include/scsi/scsi_host.h b/include/scsi/scsi_host.h
index 7e2011830ba4..500fad5ffab6 100644
--- a/include/scsi/scsi_host.h
+++ b/include/scsi/scsi_host.h
@@ -374,6 +374,15 @@ struct scsi_host_template {
 #define SCSI_ADAPTER_RESET	1
 #define SCSI_FIRMWARE_RESET	2
 
+	/*
+	 * Optional callback invoked when a device returns NOT_READY with
+	 * ASC/ASCQ = 0x04/0x11 ("notify (enable spinup) required").
+	 * This allows LLDDs to perform controller-specific spinup
+	 * notification before the mid-layer retries.
+	 *
+	 * Status: OPTIONAL
+	 */
+	void (*spinup_notify)(struct scsi_device *sdev);
 
 	/*
 	 * Name of proc directory
-- 
2.43.0

Re: [PATCH 1/2] scsi: scsi_lib: add spinup_notify callback for ASC/ASCQ=0x04/0x11

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The `spinup_notify` API lacks context documentation, risking `scheduling while atomic` bugs in hardware drivers.
- [High] Unmitigated concurrent `spinup_notify` invocations could flood LLDD hardware queues.
--

commit 171fafeb5fbd92de731525186cc8f26d24a7be8e
Author: Xingui Yang <yangxingui@huawei.com>

scsi: scsi_lib: add spinup_notify callback for ASC/ASCQ=0x04/0x11

When a SCSI device returns NOT_READY with ASC/ASCQ = 0x04/0x11 ("notify
(enable spinup) required"), the device is in Active_Wait or Idle_Wait power
state. Add an optional spinup_notify callback to struct scsi_host_template
that is invoked before ACTION_DELAYED_RETRY.

> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index daeb3693fe559..140c41a2fe03b 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -905,6 +905,10 @@ static void scsi_io_completion_action(struct scsi_cmnd *cmd, int result)
>  				case 0x1a: /* start stop unit in progress */
>  				case 0x1b: /* sanitize in progress */
>  				case 0x1d: /* configuration in progress */
> +					if (sshdr.ascq == 0x11 &&
> +					    cmd->device->host->hostt->spinup_notify)
> +						cmd->device->host->hostt->spinup_notify(
> +							cmd->device);

[Severity: High]
Could this cause a regression by flooding hardware queues with concurrent
spinup_notify invocations?

If multiple async commands are in flight when a device goes into a standby
state, they will all fail and return not ready with ascq == 0x11 almost
simultaneously.

Since scsi_io_completion_action() invokes spinup_notify unconditionally for
every command, this could cause a thundering herd.

For example, in the subsequent patch for hisi_sas, this triggers concurrent,
unlocked read-modify-write operations on the SL_CONTROL register:

hisi_sas_v3_hw.c:sl_notify_ssp_v3_hw() {
    ...
    sl_control |= SL_CONTROL_NOTIFY_EN_MSK;
    hisi_sas_phy_write32(hisi_hba, phy_no, SL_CONTROL, sl_control);
    ...
}

>  					action = ACTION_DELAYED_RETRY;
>  					break;
>  				case 0x0a: /* ALUA state transition */
> diff --git a/include/scsi/scsi_host.h b/include/scsi/scsi_host.h
> index 7e2011830ba4b..500fad5ffab68 100644
> --- a/include/scsi/scsi_host.h
> +++ b/include/scsi/scsi_host.h
> @@ -374,6 +374,15 @@ struct scsi_host_template {
>  #define SCSI_ADAPTER_RESET	1
>  #define SCSI_FIRMWARE_RESET	2
>  
> +	/*
> +	 * Optional callback invoked when a device returns NOT_READY with
> +	 * ASC/ASCQ = 0x04/0x11 ("notify (enable spinup) required").
> +	 * This allows LLDDs to perform controller-specific spinup
> +	 * notification before the mid-layer retries.
> +	 *
> +	 * Status: OPTIONAL
> +	 */
> +	void (*spinup_notify)(struct scsi_device *sdev);

[Severity: High]
Should this document the context constraints to prevent scheduling while
atomic regressions?

Since scsi_io_completion_action() is called from atomic context, any driver
implementing this callback must not sleep.

Without this documentation, it is easy to introduce bugs. For instance, the
subsequent patch in this series calls msleep(1) inside sl_notify_ssp_v3_hw()
via this callback:

hisi_sas_v3_hw.c:sl_notify_ssp_v3_hw() {
    ...
    msleep(1);
    ...
}

>  
>  	/*
>  	 * Name of proc directory

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260702035724.2059166-1-yangxingui@huawei.com?part=1

[PATCH 2/2] scsi: hisi_sas: add spinup_notify callback to handle Active_Wait/Idle_Wait SSP devices

[Xingui Yang]

When a SAS HDD disk connected via SSP (Serial Attached SCSI Protocol) is in
Active_Wait or Idle_Wait state (typical after power-up with RNOT=1), it
does not respond to standard SCSI START_STOP spinup commands. Instead it
returns NOT_READY with ASC/ASCQ = 0x04/0x11 ("notify (enable spinup)
required").

The hisi_sas controller pulses the SL_CONTROL.NOTIFY_EN bit to send a
NOTIFY(ENABLE SPINUP) primitive to the SSP device, allowing it to exit the
waiting state.

Signed-off-by: Xingui Yang <yangxingui@huawei.com>
---
 drivers/scsi/hisi_sas/hisi_sas.h       |  1 +
 drivers/scsi/hisi_sas/hisi_sas_main.c  | 25 +++++++++++++++++++++++++
 drivers/scsi/hisi_sas/hisi_sas_v1_hw.c |  1 +
 drivers/scsi/hisi_sas/hisi_sas_v2_hw.c |  1 +
 drivers/scsi/hisi_sas/hisi_sas_v3_hw.c |  1 +
 5 files changed, 29 insertions(+)

diff --git a/drivers/scsi/hisi_sas/hisi_sas.h b/drivers/scsi/hisi_sas/hisi_sas.h
index 1323ed8aa717..e198fa7f84e0 100644
--- a/drivers/scsi/hisi_sas/hisi_sas.h
+++ b/drivers/scsi/hisi_sas/hisi_sas.h
@@ -689,4 +689,5 @@ extern void hisi_sas_sync_cqs(struct hisi_hba *hisi_hba);
 extern void hisi_sas_sync_poll_cqs(struct hisi_hba *hisi_hba);
 extern void hisi_sas_controller_reset_prepare(struct hisi_hba *hisi_hba);
 extern void hisi_sas_controller_reset_done(struct hisi_hba *hisi_hba);
+extern void hisi_sas_spinup_notify(struct scsi_device *sdev);
 #endif
diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c b/drivers/scsi/hisi_sas/hisi_sas_main.c
index 944ce19ae2fc..1a16d18db297 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_main.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
@@ -2474,6 +2474,31 @@ int hisi_sas_get_fw_info(struct hisi_hba *hisi_hba)
 }
 EXPORT_SYMBOL_GPL(hisi_sas_get_fw_info);
 
+void hisi_sas_spinup_notify(struct scsi_device *sdev)
+{
+	struct domain_device *dev = sdev_to_domain_dev(sdev);
+	struct sas_ha_struct *sha;
+	struct hisi_hba *hisi_hba;
+	struct sas_phy *local_phy;
+	struct hisi_sas_phy *phy;
+
+	if (dev->parent && dev_is_expander(dev->parent->dev_type))
+		return;
+
+	sha = SHOST_TO_SAS_HA(sdev->host);
+	hisi_hba = sha->lldd_ha;
+
+	local_phy = sas_get_local_phy(dev);
+	phy = &hisi_hba->phy[local_phy->number];
+	if (phy->identify.target_port_protocols & SAS_PROTOCOL_SSP) {
+		hisi_hba->hw->sl_notify_ssp(hisi_hba, local_phy->number);
+		dev_info(hisi_hba->dev, "spinup notify on phy%d for sdev %s\n",
+			 local_phy->number, dev_name(&sdev->sdev_dev));
+	}
+	sas_put_local_phy(local_phy);
+}
+EXPORT_SYMBOL_GPL(hisi_sas_spinup_notify);
+
 static struct Scsi_Host *hisi_sas_shost_alloc(struct platform_device *pdev,
 					      const struct hisi_sas_hw *hw)
 {
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
index fa94d7110714..0179c33f08d4 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
@@ -1760,6 +1760,7 @@ static const struct scsi_host_template sht_v1_hw = {
 	.sdev_init		= hisi_sas_sdev_init,
 	.shost_groups		= host_v1_hw_groups,
 	.host_reset		= hisi_sas_host_reset,
+	.spinup_notify		= hisi_sas_spinup_notify,
 };
 
 static const struct hisi_sas_hw hisi_sas_v1_hw = {
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
index f3516a0611dd..82708a3e71c2 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
@@ -3597,6 +3597,7 @@ static const struct scsi_host_template sht_v2_hw = {
 	.host_reset		= hisi_sas_host_reset,
 	.map_queues		= map_queues_v2_hw,
 	.host_tagset		= 1,
+	.spinup_notify		= hisi_sas_spinup_notify,
 };
 
 static const struct hisi_sas_hw hisi_sas_v2_hw = {
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
index 901f508e8be7..330da2503b75 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
@@ -3417,6 +3417,7 @@ static const struct scsi_host_template sht_v3_hw = {
 	.host_reset		= hisi_sas_host_reset,
 	.host_tagset		= 1,
 	.mq_poll		= queue_complete_v3_hw,
+	.spinup_notify		= hisi_sas_spinup_notify,
 };
 
 static const struct hisi_sas_hw hisi_sas_v3_hw = {
-- 
2.43.0

Re: [PATCH 2/2] scsi: hisi_sas: add spinup_notify callback to handle Active_Wait/Idle_Wait SSP devices

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Sleep in atomic context (softirq) leading to kernel panic.
- [High] Unprotected lockless read-modify-write on the per-PHY SL_CONTROL register.
--

commit bffefed84eeb23f304d7311529b064b5addeb6c8
Author: Xingui Yang <yangxingui@huawei.com>

scsi: hisi_sas: add spinup_notify callback to handle Active_Wait/Idle_Wait SSP devices

This patch adds a spinup_notify callback to the hisi_sas controller driver to
handle SSP devices in waiting states. When a device requires spinup, the driver
sends a NOTIFY(ENABLE SPINUP) primitive by toggling the SL_CONTROL.NOTIFY_EN
bit. The callback is registered across hardware versions v1, v2, and v3.

> diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c b/drivers/scsi/hisi_sas/hisi_sas_main.c
> index 944ce19ae2fc1..1a16d18db297a 100644
> --- a/drivers/scsi/hisi_sas/hisi_sas_main.c
> +++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
> @@ -2474,6 +2474,31 @@ int hisi_sas_get_fw_info(struct hisi_hba *hisi_hba)
>  }
>  EXPORT_SYMBOL_GPL(hisi_sas_get_fw_info);
>  
> +void hisi_sas_spinup_notify(struct scsi_device *sdev)
> +{
> +	struct domain_device *dev = sdev_to_domain_dev(sdev);
> +	struct sas_ha_struct *sha;
> +	struct hisi_hba *hisi_hba;
> +	struct sas_phy *local_phy;
> +	struct hisi_sas_phy *phy;
> +
> +	if (dev->parent && dev_is_expander(dev->parent->dev_type))
> +		return;
> +
> +	sha = SHOST_TO_SAS_HA(sdev->host);
> +	hisi_hba = sha->lldd_ha;
> +
> +	local_phy = sas_get_local_phy(dev);
> +	phy = &hisi_hba->phy[local_phy->number];
> +	if (phy->identify.target_port_protocols & SAS_PROTOCOL_SSP) {
> +		hisi_hba->hw->sl_notify_ssp(hisi_hba, local_phy->number);

[Severity: High]
Does calling sl_notify_ssp() here lead to a sleep in atomic context?

When the block layer completes a request and the device requires spinup,
the SCSI completion softirq invokes scsi_complete(), which calls
scsi_decide_disposition() -> scsi_check_sense() -> spinup_notify().

Since hisi_sas_spinup_notify() executes in BLOCK_SOFTIRQ context, calling
hisi_hba->hw->sl_notify_ssp() causes a panic on v3 hardware, as it contains
msleep(1):

drivers/scsi/hisi_sas/hisi_sas_v3_hw.c:sl_notify_ssp_v3_hw() {
	...
	sl_control = hisi_sas_phy_read32(hisi_hba, phy_no, SL_CONTROL);
	sl_control |= SL_CONTROL_NOTIFY_EN_MSK;
	hisi_sas_phy_write32(hisi_hba, phy_no, SL_CONTROL, sl_control);
	msleep(1);
	...
}

[Severity: High]
Can concurrent invocations of hisi_sas_spinup_notify() clobber the
SL_CONTROL register?

Because this lockless callback path is exposed to parallel softirq contexts,
multiple I/O completions for the same device can result in concurrent
read-modify-write operations in sl_notify_ssp_v3_hw():

drivers/scsi/hisi_sas/hisi_sas_v3_hw.c:sl_notify_ssp_v3_hw() {
	...
	sl_control = hisi_sas_phy_read32(hisi_hba, phy_no, SL_CONTROL);
	sl_control |= SL_CONTROL_NOTIFY_EN_MSK;
	hisi_sas_phy_write32(hisi_hba, phy_no, SL_CONTROL, sl_control);
	...
}

Could this unprotected read-modify-write race with itself across
different CPUs, potentially leaving NOTIFY_EN permanently asserted or
overwriting state changes made by concurrent hard IRQ handlers?

> +		dev_info(hisi_hba->dev, "spinup notify on phy%d for sdev %s\n",
> +			 local_phy->number, dev_name(&sdev->sdev_dev));
> +	}
> +	sas_put_local_phy(local_phy);
> +}
> +EXPORT_SYMBOL_GPL(hisi_sas_spinup_notify);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260702035724.2059166-1-yangxingui@huawei.com?part=2

Re: [PATCH 2/2] scsi: hisi_sas: add spinup_notify callback to handle Active_Wait/Idle_Wait SSP devices

[yangxingui]

On 2026/7/2 12:20, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] Sleep in atomic context (softirq) leading to kernel panic.
> - [High] Unprotected lockless read-modify-write on the per-PHY SL_CONTROL register.

I'll update in next version, hisi_sas_spinup_notify() no longer calls 
sl_notify_ssp() directly. Instead, it queues a new 
HISI_PHYE_SPINUP_NOTIFY work item onto the driver's private workqueue 
(hisi_hba->wq) via hisi_sas_notify_phy_event().


Thanks,
Xingui