On 10/18/23 03:03, Phillip Susi wrote: > Damien Le Moal <dlemoal@xxxxxxxxxx> writes: > >> That one should be fixable, though it I do not see an elegant method to do it. >> It would be easy with ugly code, e.g. tweaking the scsi device runtime pm state >> from libata... Not great. > > What would be not great about it? libata already takes over the system > suspend/resume from sd. I'm currently testing having libata do just > this right now. I just got ahold of some jumpers today to put the > drives back into PuiS and do some further testing tonight. > >> Never saw that in my tests when enabling runtime pm on the scsi disk only. Which >> is the important point here: there is no propagation of the suspend state down >> to the device parent it seems. > > Last night I again saw the port auto suspend when the scsi disk was > runtime suspended. Tonight I'll test with PuiS, as well as with system > resume while runtime suspended. Maybe I'll even try to get the whole > AHCI controller to auto suspend. It seems like it should once all of > the ports do. > >> I am not sure of that, especially with cases of ATA ports with multiple disks >> (e.g. pmp or IDE). > > Good point. I have an eSATA dock with PMP. I'll check tonight if the > children are counted properly. On my system, I see: cat /sys/class/ata_port/ata1/power/runtime_active_kids 0 and same for port 10 which is a PMP box with 3 drives. So it means that the children will be ignored, which is wrong. Note that the corresponding scsi_host device also shows 0. So to be safe with port runtime PM, we need to fix that first. Otherwise, the port may end up being runtime suspended with running drives still attached to it. /sys/class/ata_port/ata1/power/control is set to "auto" by default. -- Damien Le Moal Western Digital Research
