On 1/6/24 01:30, Phillip Susi wrote: > Damien Le Moal <dlemoal@xxxxxxxxxx> writes: > >> What ? If you wake up the drive, it will not be in standby... So I do not get >> your point here. Can you clarify ? What is the problem you are trying to solve >> here ? Is it related to system or runtime suspend/resume ? > > The whole point is that we don't want to spin up the drive. A drive > that is in standby simply treats these commands as a NOOP. One that is > in SLEEP can not do that, so we must do it for the drive. But who is issuing these commands ? If it is systemd/udev, then *that* need to be patched to avoid it issuing these commands when the drive is sleeping. Otherwise, there is no end to this. Next time systemd/udev is modified and start issuing another command, we'll need to ignore that one as well. This is a dangerous path that I am not willing to accept. That would mean having a sysfs attribute indicating that the device is sleeping though. So the sleep case needs more work. > Without this patch, SLEEP mode is basically useless since the drive will > be woken up by one of these commands quite soon after you put it to > SLEEP.> > This is just to make hdparm -Y not useless. It has nothing to do with > suspend/resume. I was thinking of splitting this patch series into two > parts, one with just the patches related to SLEEP and one with the > patches related to suspend/resume. As long as you can only set sleep mode with hdparm, there is not much we can do. hdparm uses passthrough commands, and so handling whatever that tool does in the kernel becomes a nightmare as libata would need to parse the issued commands and handle their result. Only a few cases are done now. Extending that would be difficult and fragile. Rather, I would recommend improving the runtime pm code to allow for "going to sleep" instead of "going to standby". A sysfs attribute switch can be used for that, with the default being standby like now. And yes, please split the series ! One for what you want to do for puis and another for improved sleep handling. Everything together is simply too confusing. -- Damien Le Moal Western Digital Research
