When a SAS device is in the Active_Wait or Idle_Wait power state, it
returns NOT_READY with ASC/ASCQ = 0x04/0x11 (notify (enable spinup)
required), indicating that a NOTIFY(ENABLE SPINUP) primitive is needed to
trigger media spinup.

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 entirely within the SAS transport
layer (libsas), reusing the existing phy event framework, without modifying
the generic SCSI mid-layer. This addresses the review feedback from
John Garry on v2.

Changes in v3 (addressing John Garry's review on v2):
- Move spinup notification from scsi_host_template to libsas. Reuse
  the existing phy event framework: add PHYE_NOTIFY_ENABLE_SPINUP
  and lldd_notify_enable_spinup callback.
- Sense detection in sas_ssp_task_response() covers all SAS LLDDs.

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: libsas: Add PHYE_NOTIFY_ENABLE_SPINUP phy event for
    ASC/ASCQ=0x04/0x11
  scsi: hisi_sas: Add lldd_notify_enable_spinup callback for SAS devices

 drivers/scsi/hisi_sas/hisi_sas_main.c | 11 +++++++
 drivers/scsi/libsas/sas_internal.h    |  2 ++
 drivers/scsi/libsas/sas_phy.c         | 12 +++++++
 drivers/scsi/libsas/sas_scsi_host.c   | 45 +++++++++++++++++++++++++++
 drivers/scsi/libsas/sas_task.c        |  2 ++
 include/scsi/libsas.h                 |  9 ++++++
 6 files changed, 81 insertions(+)

-- 
2.43.0

On 03/08/2026 03:05, Xingui Yang wrote:
> When a SAS device is in the Active_Wait or Idle_Wait power state, it
> returns NOT_READY with ASC/ASCQ = 0x04/0x11 (notify (enable spinup)
> required), indicating that a NOTIFY(ENABLE SPINUP) primitive is needed to
> trigger media spinup.
> 
> 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.
> 

How would other SAS HBAs which use libsas handle this scenario? Since 
they have FW, would the FW automatically issue this NOTIFY(ENABLE SPINUP)?

I just wonder why hisi_sas seems to be only driver which would need this.

> This patch series addresses the issue entirely within the SAS transport
> layer (libsas), reusing the existing phy event framework, without modifying
> the generic SCSI mid-layer. This addresses the review feedback from
> John Garry on v2.
> 
> Changes in v3 (addressing John Garry's review on v2):
> - Move spinup notification from scsi_host_template to libsas. Reuse
>    the existing phy event framework: add PHYE_NOTIFY_ENABLE_SPINUP
>    and lldd_notify_enable_spinup callback.
> - Sense detection in sas_ssp_task_response() covers all SAS LLDDs.
> 
> 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: libsas: Add PHYE_NOTIFY_ENABLE_SPINUP phy event for
>      ASC/ASCQ=0x04/0x11
>    scsi: hisi_sas: Add lldd_notify_enable_spinup callback for SAS devices
> 
>   drivers/scsi/hisi_sas/hisi_sas_main.c | 11 +++++++
>   drivers/scsi/libsas/sas_internal.h    |  2 ++
>   drivers/scsi/libsas/sas_phy.c         | 12 +++++++
>   drivers/scsi/libsas/sas_scsi_host.c   | 45 +++++++++++++++++++++++++++
>   drivers/scsi/libsas/sas_task.c        |  2 ++
>   include/scsi/libsas.h                 |  9 ++++++
>   6 files changed, 81 insertions(+)
>

Hi John

On 2026/8/4 15:35, John Garry wrote:
> On 03/08/2026 03:05, Xingui Yang wrote:
>> When a SAS device is in the Active_Wait or Idle_Wait power state, it
>> returns NOT_READY with ASC/ASCQ = 0x04/0x11 (notify (enable spinup)
>> required), indicating that a NOTIFY(ENABLE SPINUP) primitive is needed to
>> trigger media spinup.
>>
>> 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.
>>
> 
> How would other SAS HBAs which use libsas handle this scenario? Since 
> they have FW, would the FW automatically issue this NOTIFY(ENABLE SPINUP)?
> 
> I just wonder why hisi_sas seems to be only driver which would need this.

Thanks for the question. This affects only SAS HDDs. I checked pm8001, 
isci, and aic94xx — all handle NOTIFY(ENABLE SPINUP) at the driver level:

- pm8001: sends once at phy-up, then mdelay(200) — comment: "delay a 
moment to wait disk to spinup" — before notifying libsas.

- isci: enables hardware periodic insertion during link idle (ENABLE bit 
in notify_enable_spinup_control), cleared at phy stop.

- aic94xx: enables microcode periodic insertion during link idle 
(NOTIFY_TIMER_TIMEOUT = 500ms interval), stops at phy down.

hisi_sas also calls sl_notify_ssp() at phy-up, but the NOTIFY_EN bit is 
held for only 1ms — msleep(1) between setting and clearing — before 
immediately notifying libsas.

The root cause appears to be that 1ms is insufficient compared to 
pm8001's 200ms. An alternative to hisi_sas would be to simply increase 
the hold time in sl_notify_ssp() to match pm8001's approach, keeping the 
fix within hisi_sas.

Would you prefer this simpler approach, or do you still see value in the 
libsas-level sense detection and callback from hisi_sas? ^-^


Thanks,
Xingui Yang

On 2026/8/4 17:30, yangxingui wrote:
> Hi John
> 
> On 2026/8/4 15:35, John Garry wrote:
>> On 03/08/2026 03:05, Xingui Yang wrote:
>>> When a SAS device is in the Active_Wait or Idle_Wait power state, it
>>> returns NOT_READY with ASC/ASCQ = 0x04/0x11 (notify (enable spinup)
>>> required), indicating that a NOTIFY(ENABLE SPINUP) primitive is 
>>> needed to
>>> trigger media spinup.
>>>
>>> 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.
>>>
>>
>> How would other SAS HBAs which use libsas handle this scenario? Since 
>> they have FW, would the FW automatically issue this NOTIFY(ENABLE 
>> SPINUP)?
>>
>> I just wonder why hisi_sas seems to be only driver which would need this.
> 
> Thanks for the question. This affects only SAS HDDs. I checked pm8001, 
> isci, and aic94xx — all handle NOTIFY(ENABLE SPINUP) at the driver level:
> 
> - pm8001: sends once at phy-up, then mdelay(200) — comment: "delay a 
> moment to wait disk to spinup" — before notifying libsas.
> 
> - isci: enables hardware periodic insertion during link idle (ENABLE bit 
> in notify_enable_spinup_control), cleared at phy stop.
> 
> - aic94xx: enables microcode periodic insertion during link idle 
> (NOTIFY_TIMER_TIMEOUT = 500ms interval), stops at phy down.
> 
> hisi_sas also calls sl_notify_ssp() at phy-up, but the NOTIFY_EN bit is 
> held for only 1ms — msleep(1) between setting and clearing — before 
> immediately notifying libsas.
> 
> The root cause appears to be that 1ms is insufficient compared to 
> pm8001's 200ms. An alternative to hisi_sas would be to simply increase 
> the hold time in sl_notify_ssp() to match pm8001's approach, keeping the 
> fix within hisi_sas.

When NOTIFY_EN is configured, the hardware sends only a single spinup 
notify primitive, and adjusting the sleep duration has no effect. 
However, TRI_NOTIFY_EN bit (bit 1), the hardware can send three notify 
primitives, which helps alleviate this issue.

Thanks,
Xingui

On 04/08/2026 10:30, yangxingui wrote:
>>
>> How would other SAS HBAs which use libsas handle this scenario? Since 
>> they have FW, would the FW automatically issue this NOTIFY(ENABLE 
>> SPINUP)?
>>
>> I just wonder why hisi_sas seems to be only driver which would need this.
> 
> Thanks for the question. This affects only SAS HDDs. I checked pm8001, 
> isci, and aic94xx — all handle NOTIFY(ENABLE SPINUP) at the driver level:
> 
> - pm8001: sends once at phy-up, then mdelay(200) — comment: "delay a 
> moment to wait disk to spinup" — before notifying libsas.
> 
> - isci: enables hardware periodic insertion during link idle (ENABLE bit 
> in notify_enable_spinup_control), cleared at phy stop.
> 
> - aic94xx: enables microcode periodic insertion during link idle 
> (NOTIFY_TIMER_TIMEOUT = 500ms interval), stops at phy down.
> 
> hisi_sas also calls sl_notify_ssp() at phy-up, but the NOTIFY_EN bit is 
> held for only 1ms — msleep(1) between setting and clearing — before 
> immediately notifying libsas.
> 
> The root cause appears to be that 1ms is insufficient compared to 
> pm8001's 200ms. An alternative to hisi_sas would be to simply increase 
> the hold time in sl_notify_ssp() to match pm8001's approach, keeping the 
> fix within hisi_sas.
> 
> Would you prefer this simpler approach, or do you still see value in the 
> libsas-level sense detection and callback from hisi_sas? ^-^

I think that if you can resolve this in the LL driver then that would be 
better.

On 2026/8/5 19:43, John Garry wrote:
> On 04/08/2026 10:30, yangxingui wrote:
>>>
>>> How would other SAS HBAs which use libsas handle this scenario? Since 
>>> they have FW, would the FW automatically issue this NOTIFY(ENABLE 
>>> SPINUP)?
>>>
>>> I just wonder why hisi_sas seems to be only driver which would need 
>>> this.
>>
>> Thanks for the question. This affects only SAS HDDs. I checked pm8001, 
>> isci, and aic94xx — all handle NOTIFY(ENABLE SPINUP) at the driver level:
>>
>> - pm8001: sends once at phy-up, then mdelay(200) — comment: "delay a 
>> moment to wait disk to spinup" — before notifying libsas.
>>
>> - isci: enables hardware periodic insertion during link idle (ENABLE 
>> bit in notify_enable_spinup_control), cleared at phy stop.
>>
>> - aic94xx: enables microcode periodic insertion during link idle 
>> (NOTIFY_TIMER_TIMEOUT = 500ms interval), stops at phy down.
>>
>> hisi_sas also calls sl_notify_ssp() at phy-up, but the NOTIFY_EN bit 
>> is held for only 1ms — msleep(1) between setting and clearing — before 
>> immediately notifying libsas.
>>
>> The root cause appears to be that 1ms is insufficient compared to 
>> pm8001's 200ms. An alternative to hisi_sas would be to simply increase 
>> the hold time in sl_notify_ssp() to match pm8001's approach, keeping 
>> the fix within hisi_sas.
>>
>> Would you prefer this simpler approach, or do you still see value in 
>> the libsas-level sense detection and callback from hisi_sas? ^-^
> 
> I think that if you can resolve this in the LL driver then that would be 
> better.

Okay, thanks a lot.

Xingui