[CC: list drastically trimmed] On Wed, Jun 24, 2020 at 09:22:42AM +0200, Martin Kepplinger wrote: > On 23.06.20 16:54, Alan Stern wrote: > > I don't understand this. As far as I know, runtime-PM support in the SCSI > > and block layers has been complete for many years. If you have to do > > anything extra (like applying the patch in the email you mentioned) then > > something is broken. The device should be able to go into runtime suspend > > just fine with the current code -- even when a file system is mounted. > > > > The scsi and usb layers have good implementations for runtime pm for a > long time indeed. The scsi drivers though vary: for example sr indeed > suspends when unused, when mounted and open too. > > look at the sd driver in comparison though: From what I see, it "uses" > autopm (runtime pm) as it would let the device suspend, but never > resumes from it (except when removing and probing again). My suspicion > is that it's not really used for that reason. > > I might be wrong of course - I usually don't look at scsi code and I'm > so thankful for feedback. That's what I read though and also what my > tests verify. Hence the patch to the sd driver that makes enabling > runtime pm result in a usable device (granted, not yet saving as much > power as it really could, but that can be added later). I haven't looked at this code or tested it for a long time, so maybe it isn't working properly. Still, here's the general idea of how it's _intended_ to work: The runtime PM control for sd lies not in the sd driver itself but in the block layer core. If a SCSI drive is suspended when a block request is issued, the block layer initiates a runtime resume. See the kerneldoc for blk_pm_runtime_init() and the following functions in block/blk-pm.c. If you need a more detailed explanation, please ask. Alan Stern
