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?