On 11/09/2023 07:48, Damien Le Moal wrote:
#define ATA_BASE_SHT(drv_name) \
I do understand the rationale here, as the relationship between ata port and
scsi devices are blurred. Question is: blurred by what?
Is it the libata/SAS duality where SCSI devices will have a different
ancestry for libata and libsas?
If so, why don't we need the 'link' mechanism for SAS?
Or is it something else?
On scsi, ancestry from Scsi_Host is clear: host->target->device->disk.
For ATA, it is also clear: port->link->device
The relationship is that ata port has its own Scsi_Host, but no "family"
relationship here. They are just "friends", so scsi disk and ata_port have no
direct ancestry. Adding the link creates that.
libsas does not need the link because it does its own PM management of the
ports, not relying on PM to order things.
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
I think that this should really be added for all libsas drivers which
support RPM - pm8001 is missing, IIRC.