On 11/09/2023 12:48, Damien Le Moal wrote:
For hisi_sas v3, RPM is supported and a link was required to be added in
that driver between the sdev and those host controller device - see
16fd4a7c59. And that is for a similar reason here. I see that we already
have an ancestry for libata between ata_dev -> ata_link -> ata_port ->
ata_host dev, so it seems reasonable to add ata_dev <-> sdev dependency
libata creates a link between ata_port and sdev. This is not very natural, but
as I said in the cover letter, the power management model is weird as everything
is per port, even if a port has multiple devices. Nevertheless, I tried to apply
the same for libsas but failed: if I add the link creation in the slave_alloc
method, I fail to get the scsi disks to show up (no /dev/sdX device files). Not
sure why. That was with my pm8001 adapter, which is the only libsas one I have.
Side note: having an ata_debug (ata equivalent of scsi_debug) driver that could
act as a pure libata driver or as a libsas adapter would really be awesome for
this kind of tests 😄
hmm... maybe scsi_debug could be modified to support ATA devices (with
Regardless, I'm happy to check the code change which you attempted if
I think that this should really be added for all libsas drivers which
support RPM - pm8001 is missing, IIRC.
Will try again tomorrow looking at hisi driver for inspiration. The other thing
I need to better understand is how the suspend & resume operations of libsas get
triggered. For suspend, it is easy-ish, but for resume, it seems to be tightly
coupled with discovery, so the the adapter resume (scsi host class resume ?).
If that is the case, then that is done*before* the scsi_dev resume because of
the existing device link dependencies. So I am not yet entirely convinced that
adding a link between ata_port and sdev will serve any purpose now that the
asynchronous libata resume is fixed and synchronized with the scsi disk
resume... Will dig further.
That said, it may be good to move libsas suspend/resume fixes to another patch
series. There is an outstanding regression/problem for pure libata devices that
this series fixes. So would like to get the fixes patches in Linus tree ASAP.
Sure, and I do realize that libsas is outside the scope of this series.