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

[yangxingui <yangxingui@huawei.com>]

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