On Fri, Nov 01, 2024 at 10:11:11AM +0800, Jason Wang wrote:

On Fri, Nov 1, 2024 at 9:54 AM [off-list ref] wrote:

quoted

From: Qiang Zhang <redacted>

Virtio core unconditionally reset and restore status for all virtio
devices before calling restore method. This breaks some virtio drivers
which don't need to do anything in suspend and resume because they
just want to keep device state retained.

The challenge is how can driver know device doesn't need rest.

I actually don't remember why do we do reset on restore. Do you?

For example, PCI has no_soft_reset which has been done in the commit
"virtio: Add support for no-reset virtio PCI PM".

And there's a ongoing long discussion of adding suspend support in the
virtio spec, then driver know it's safe to suspend/resume without
reset.

quoted

Virtio GPIO is a typical example. GPIO states should be kept unchanged
after suspend and resume (e.g. output pins keep driving the output) and
Virtio GPIO driver does nothing in freeze and restore methods. But the
reset operation in virtio_device_restore breaks this.

Is this mandated by GPIO or virtio spec? If yes, let's quote the revelant part.

quoted

Since some devices need reset in suspend and resume while some needn't,
create a new helper function for the original reset and status restore
logic so that virtio drivers can invoke it in their restore method
if necessary.

How are those drivers classified?

quoted

Signed-off-by: Qiang Zhang <redacted>

Thanks