Damien Le Moal <dlemoal@xxxxxxxxxx> writes:
> See ata_dev_revalidate() and ata_dev_configure() and all the drive features that
> are checked using the identify data. We need to preserve that to ensure that
> nothing changed on the drive so that its representation in libata is kept in
> sync with the drive config. That is why drive starting with PUIS and not giving
> full identify data *must* be woken up, which is the current libata behavior.
Yes, the information is needed to revalidate, but why must this
revalidation be done during system resume, rather than postponed until later?
> You do not need to change the hierarchy of devices. An ata_dev is already a
> child of its scsi_dev. So if you want to set the ata device to runtime
> suspend
How is an ata_dev a child of its own scsi_dev? Or did you mean to say
the reverse: the scsi_dev is a child of the ata_dev? But that isn't the
case either. In sysfs, you have:
ata_port
- scsi_host
- scsi_target
- scsi_lun
- ata_link
- ata_dev
The link and dev hang off to the side, not in the ancestry of the scsi
disk.
> state, you have to have the parent in the same state too. runtime suspend work
> top-to-bottom in the device chain. You cannot have random device in the middle
> of the chain going to suspend without the devices above it also being suspended.
>
> Also, the user does not use ata devices directly. They use the scsi device
> representing the ata device. You must thus have that in sync with the ata device
> state.
Right... so when the system is resumed, first the ata_port is resumed,
then it has to be on for the scsi host, target, and lun to resume. At
that point sd could check if the disk is actually spinning, and if not,
force it to suspend, which then allows the target to suspend, wich then
allows the host to suspend, and finally the ata_port.
