Damien Le Moal <dlemoal@xxxxxxxxxx> writes: > With the device links in place between port and scsi devices, we should be OK. > But still need to check that we do not need runtime_get/put calls added. > Ideally, we should have the chain: > > scsi disk -> scsi target -> scsi host -> ata port It looks to me like there is an additional generic block device that sits on top and that is what actually has the idle timeout. Or maybe that's the scsi disk, since it's name incldues the SCSI LUN, but in the structure, its called sdev_gendev. But then there's also sdev_dev, and sdev_target. > for runtime suspend, and the reverse for runtime resume. If there is a system > suspend/resume between runtime suspend/resume, the port should not be resumed if > it is runtime suspended. I'm not sure about it. The port has to be resumed so that we can attempt to revalidate the devices on it. For disks that have spun up on their own, we should not leave then marked as runtime suspended, but really they are spinning. I suppose we could put them to sleep, though I was leaning to just marking them as active, and leaving the runtime pm timer to put them to sleep later, which then could allow the port to suspend again.
