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

[John Garry <john.g.garry@oracle.com>]

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?