Damien Le Moal <dlemoal@xxxxxxxxxx> writes: > Why ? The drive is in standby. What is the point of putting it into > sleep state I just figured it would save a little more power than just *pretending* the drive was asleep ( which is what I did at first ). I guess I can go back to just setting the sleeping flag without telling the drive to actually go to sleep. > ? Furthermore, if you check ACS-6 specs, you will see that there is no > transitions defined from PUIS state to sleep state. You have to spin-up the > drive first. So the above is outside the specified behavior and thus not > reliable (even though many drive may actually allow this transition). Oh poo. Though now I'm curious if it actually does fail on any. It seems like a pretty obvious thing to do and an oversight on the part of the spec. The kernel certainly doesn't do anything to prevent the user from running hdparm -Y on a drive that is already in standby. Wait, is that specifically from PuiS to sleep, or standby to sleep in general? > Rather than playing with the return values, it may be easier to use a device > flag (similar to ATA_DFLAG_SLEEPING) to track standby/spun-down state. You mean change each if (rc == -EAGAIN) to if (ATA_DFLAG_SLEEPING)? That doesn't seem any easier to me, but I'm not opposed to it. >> + pm_runtime_resume(&dev->sdev->sdev_gendev); > > What does this do ??? This look really out of place. Darnit, I thought I had removed all of the runtime pm stuff. My bad.
