On 11/7/23 22:27, Phillip Susi wrote: > Damien Le Moal <dlemoal@xxxxxxxxxx> writes: > >> That is because the PM operations are defined for the *port*, not the *device* >> (struct ata_device). With the missing PM ops for the device, PM core simply >> sets the device as active. > > The ata device appears to be entirely internal and not exposed as part > of the sysfs device tree. It is the generic block device that seems to > be the one that actually implements runtime pm for the disk. > > I think the problem is that the ata port is resumed first, then later > the block device. Thus, setting the block device to suspended in the > port resume is later overruled by the system resume of the block > device. I'm thinking what is needed is for sd.c to query libata in its > system resume callback and then set the runtime pm status depending on > whether the drive is active or not. Nope. The correct way to do this would be to define PM operations for the ata device. However, currently, the scsi_device (scsi_disk) parent is the ata_port, so to make sure that the PM status of the parent propagates to the child correctly, we would need to have the scsi_device parent set to the ata_device. As I said, correcting this is not simple and will involve a significant amount of changes. > By the way, I have noticed my system logs showing that the ata port that > my dvd+rw is on is "Activating" twice, back to back. Any idea why it > would be trying to power up the optial drive twice? Please send the exact messages you see in dmesg. > -- Damien Le Moal Western Digital Research