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

[PATCH v2 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.

Changes in v2 (addressing Sashiko AI review on v1):
- Add softirq context documentation to spinup_notify in scsi_host.h
- Defer sl_notify_ssp() to ordered workqueue, fixing msleep-in-
  atomic bug, preventing RMW races on SL_CONTROL, and deduplicating
  concurrent callbacks via queue_work()

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       |  2 ++
 drivers/scsi/hisi_sas/hisi_sas_main.c  | 34 ++++++++++++++++++++++++++
 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               | 12 +++++++++
 7 files changed, 55 insertions(+)

-- 
2.43.0

[PATCH v2 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 | 12 ++++++++++++
 2 files changed, 16 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..22bf2d3d9b36 100644
--- a/include/scsi/scsi_host.h
+++ b/include/scsi/scsi_host.h
@@ -374,6 +374,18 @@ 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.
+	 *
+	 * Context: Called from softirq (block layer completion) context.
+	 * Implementations must not sleep or schedule.
+	 *
+	 * Status: OPTIONAL
+	 */
+	void (*spinup_notify)(struct scsi_device *sdev);
 
 	/*
 	 * Name of proc directory
-- 
2.43.0

[PATCH v2 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.

Because the spinup_notify callback runs in softirq context and
sl_notify_ssp() contains msleep(1), the callback queues a
HISI_PHYE_SPINUP_NOTIFY work item to the driver's ordered workqueue
(hisi_hba->wq) and defers the actual hardware access to process context.
The ordered workqueue serializes execution, preventing concurrent RMW
races on SL_CONTROL, and queue_work() deduplicates concurrent invocations.

Signed-off-by: Xingui Yang <yangxingui@huawei.com>
---
 drivers/scsi/hisi_sas/hisi_sas.h       |  2 ++
 drivers/scsi/hisi_sas/hisi_sas_main.c  | 34 ++++++++++++++++++++++++++
 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, 39 insertions(+)

diff --git a/drivers/scsi/hisi_sas/hisi_sas.h b/drivers/scsi/hisi_sas/hisi_sas.h
index 1323ed8aa717..6e21af66442d 100644
--- a/drivers/scsi/hisi_sas/hisi_sas.h
+++ b/drivers/scsi/hisi_sas/hisi_sas.h
@@ -163,6 +163,7 @@ enum hisi_sas_phy_event {
 	HISI_PHYE_PHY_UP   = 0U,
 	HISI_PHYE_LINK_RESET,
 	HISI_PHYE_PHY_UP_PM,
+	HISI_PHYE_SPINUP_NOTIFY,
 	HISI_PHYES_NUM,
 };
 
@@ -689,4 +690,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..14cf01466a75 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_main.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
@@ -996,10 +996,22 @@ static void hisi_sas_phyup_pm_work(struct work_struct *work)
 	pm_runtime_put_sync(dev);
 }
 
+static void hisi_sas_spinup_notify_work(struct work_struct *work)
+{
+	struct hisi_sas_phy *phy =
+		container_of(work, typeof(*phy), works[HISI_PHYE_SPINUP_NOTIFY]);
+	struct hisi_hba *hisi_hba = phy->hisi_hba;
+	int phy_no = phy->sas_phy.id;
+
+	hisi_hba->hw->sl_notify_ssp(hisi_hba, phy_no);
+	dev_info(hisi_hba->dev, "spinup notify primitive on phy%d\n", phy_no);
+}
+
 static const work_func_t hisi_sas_phye_fns[HISI_PHYES_NUM] = {
 	[HISI_PHYE_PHY_UP] = hisi_sas_phyup_work,
 	[HISI_PHYE_LINK_RESET] = hisi_sas_linkreset_work,
 	[HISI_PHYE_PHY_UP_PM] = hisi_sas_phyup_pm_work,
+	[HISI_PHYE_SPINUP_NOTIFY] = hisi_sas_spinup_notify_work,
 };
 
 bool hisi_sas_notify_phy_event(struct hisi_sas_phy *phy,
@@ -2474,6 +2486,28 @@ 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_sas_notify_phy_event(phy, HISI_PHYE_SPINUP_NOTIFY);
+	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 v2 0/2] scsi: support spinup notification for SAS SSP devices in Active_Wait/Idle_Wait state

[yangxingui]

Kindly ping for review...

On 2026/7/3 10:28, Xingui Yang wrote:
> 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.
> 
> Changes in v2 (addressing Sashiko AI review on v1):
> - Add softirq context documentation to spinup_notify in scsi_host.h
> - Defer sl_notify_ssp() to ordered workqueue, fixing msleep-in-
>    atomic bug, preventing RMW races on SL_CONTROL, and deduplicating
>    concurrent callbacks via queue_work()
> 
> 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       |  2 ++
>   drivers/scsi/hisi_sas/hisi_sas_main.c  | 34 ++++++++++++++++++++++++++
>   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               | 12 +++++++++
>   7 files changed, 55 insertions(+)
> 


Thanks,
Xingui

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

[John Garry]

On 03/07/2026 03:28, Xingui Yang wrote:

+

> 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 | 12 ++++++++++++
>   2 files changed, 16 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..22bf2d3d9b36 100644
> --- a/include/scsi/scsi_host.h
> +++ b/include/scsi/scsi_host.h
> @@ -374,6 +374,18 @@ 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.
> +	 *
> +	 * Context: Called from softirq (block layer completion) context.
> +	 * Implementations must not sleep or schedule.
> +	 *
> +	 * Status: OPTIONAL
> +	 */
> +	void (*spinup_notify)(struct scsi_device *sdev);

I am not sure that adding a sht callback for a protocol issue is the 
best thing for this.

I'll check for other methods which could  be used. Hannes, any suggestion?

>   
>   	/*
>   	 * Name of proc directory

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

[John Garry]

+

>   
> +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_sas_notify_phy_event(phy, HISI_PHYE_SPINUP_NOTIFY);
> +	sas_put_local_phy(local_phy);
> +}
> +EXPORT_SYMBOL_GPL(hisi_sas_spinup_notify);
This could go in libsas

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

[yangxingui]

On 2026/7/20 17:47, John Garry wrote:
> +
> 
>> +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_sas_notify_phy_event(phy, HISI_PHYE_SPINUP_NOTIFY);
>> +    sas_put_local_phy(local_phy);
>> +}
>> +EXPORT_SYMBOL_GPL(hisi_sas_spinup_notify);
> This could go in libsas

Hi, John.
Are you suggesting that we add an event like `PHYE_NOTIFY_ENABLE_SPINUP` 
and a callback like `lldd_notify_enable_spinup` to libsas? If so, should 
libsas parse the sense data directly—for instance, by handling it within 
the `sas_ssp_task_response()` function?

Thanks,
Xingui

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

[John Garry]

On 21/07/2026 12:10, yangxingui wrote:
> 
> 
> On 2026/7/20 17:47, John Garry wrote:
>> +
>>
>>> +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_sas_notify_phy_event(phy, HISI_PHYE_SPINUP_NOTIFY);
>>> +    sas_put_local_phy(local_phy);
>>> +}
>>> +EXPORT_SYMBOL_GPL(hisi_sas_spinup_notify);
>> This could go in libsas
> 
> Hi, John.
> Are you suggesting that we add an event like `PHYE_NOTIFY_ENABLE_SPINUP` 
> and a callback like `lldd_notify_enable_spinup` to libsas? If so, should 
> libsas parse the sense data directly—for instance, by handling it within 
> the `sas_ssp_task_response()` function?

Yeah, it would be something like that.

But the method to solve this issue is unclear.

Back to the original issue: hisi_sas_spinup_notify_work() calls 
sl_notify_ssp, but sl_notify_ssp is called already in 
hisi_sas_phyup_work_common() - so why is it needed to be called again? 
If it is because hisi_sas_phyup_work_common() is only for 
direct-attached disks, and we need to call sl_notify_ssp for expander 
attached disks?

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

[yangxingui]

On 2026/7/21 20:33, John Garry wrote:
> On 21/07/2026 12:10, yangxingui wrote:
>>
>>
>> On 2026/7/20 17:47, John Garry wrote:
>>> +
>>>
>>>> +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_sas_notify_phy_event(phy, HISI_PHYE_SPINUP_NOTIFY);
>>>> +    sas_put_local_phy(local_phy);
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(hisi_sas_spinup_notify);
>>> This could go in libsas
>>
>> Hi, John.
>> Are you suggesting that we add an event like 
>> `PHYE_NOTIFY_ENABLE_SPINUP` and a callback like 
>> `lldd_notify_enable_spinup` to libsas? If so, should libsas parse the 
>> sense data directly—for instance, by handling it within the 
>> `sas_ssp_task_response()` function?
> 
> Yeah, it would be something like that.
> 
> But the method to solve this issue is unclear.
> 
> Back to the original issue: hisi_sas_spinup_notify_work() calls 
> sl_notify_ssp, but sl_notify_ssp is called already in 
> hisi_sas_phyup_work_common() - so why is it needed to be called again? 
In fact, the trigger for this point sometimes fails to take effect.

> If it is because hisi_sas_phyup_work_common() is only for 
> direct-attached disks, and we need to call sl_notify_ssp for expander 
> attached disks?

NOTIFY(SPIN UP) is primarily intended for direct-attached HDD wake-up 
post-IDENTIFY exchange. Routing it to an Expander may conflict with SAS 
topology constraints and could disrupt link-layer arbitration, 
indicating that a conditional disable mechanism for cfg_notify_en in 
non-direct topologies is advisable.

Thank,
Xingui
.

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

[John Garry]

On 21/07/2026 14:33, yangxingui wrote:
>>
>> Yeah, it would be something like that.
>>
>> But the method to solve this issue is unclear.
>>
>> Back to the original issue: hisi_sas_spinup_notify_work() calls 
>> sl_notify_ssp, but sl_notify_ssp is called already in 
>> hisi_sas_phyup_work_common() - so why is it needed to be called again? 
> In fact, the trigger for this point sometimes fails to take effect.
> 
>> If it is because hisi_sas_phyup_work_common() is only for direct- 
>> attached disks, and we need to call sl_notify_ssp for expander 
>> attached disks?
> 
> NOTIFY(SPIN UP) is primarily intended for direct-attached HDD wake-up 
> post-IDENTIFY exchange. Routing it to an Expander may conflict with SAS 
> topology constraints and could disrupt link-layer arbitration, 
> indicating that a conditional disable mechanism for cfg_notify_en in 
> non-direct topologies is advisable.

This problem which you are trying to solve is only for direct-attached 
disks, right?

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

[yangxingui]

Hi, John.

On 2026/7/22 16:47, John Garry wrote:
> On 21/07/2026 14:33, yangxingui wrote:
>>>
>>> Yeah, it would be something like that.
>>>
>>> But the method to solve this issue is unclear.
>>>
>>> Back to the original issue: hisi_sas_spinup_notify_work() calls 
>>> sl_notify_ssp, but sl_notify_ssp is called already in 
>>> hisi_sas_phyup_work_common() - so why is it needed to be called again? 
>> In fact, the trigger for this point sometimes fails to take effect.
>>
>>> If it is because hisi_sas_phyup_work_common() is only for direct- 
>>> attached disks, and we need to call sl_notify_ssp for expander 
>>> attached disks?
>>
>> NOTIFY(SPIN UP) is primarily intended for direct-attached HDD wake-up 
>> post-IDENTIFY exchange. Routing it to an Expander may conflict with 
>> SAS topology constraints and could disrupt link-layer arbitration, 
>> indicating that a conditional disable mechanism for cfg_notify_en in 
>> non-direct topologies is advisable.
> 
> This problem which you are trying to solve is only for direct-attached 
> disks, right?

Yeah, I consulted the developer responsible for the Expander firmware, 
the firmware proactively sends a "spin-up" primitive when a sas disk is 
connected and specific conditions are met.

Based on the document below:
https://www.t10.org/ftp/t10/document.02/02-360r1.pdf

"7.1.4 SAS primitives
7.1.4.n SPINUP
...
Initiator devices and expander devices shall transmit SPINUPs while 
attached to target devices (i.e., devices
that report any target protocol support in their IDENTIFY address 
frames). They shall transmit one SPINUP
after power on when the enclosure is ready for initial target device 
spin-up. After the initial SPINUP, they shall
transmit SPINUP periodically.
...

SPINUP shall not be forwarded through expander devices."

Thanks,
Xingui