linux-toradex.git/drivers/virtio/virtio_pci.c, branch v3.4.62

virtio-pci: switch to PM ops macro to initialise PM functions

2012-03-31T02:39:51+00:00

Use the SET_SYSTEM_SLEEP_PM_OPS macro to initialise the suspend/resume
functions in the new PM API.

Signed-off-by: Amit Shah

virtio-pci: S3 support

2012-03-31T02:39:51+00:00

There's no difference in supporting S3 and S4 for virtio devices: the
vqs have to be re-created as the device has to be assumed to be reset at
restore-time.  Since S4 already handles this situation, we can directly
use the same code and callbacks for S3 support.

Signed-off-by: Amit Shah

virtio-pci: drop restore_common()

2012-03-31T02:39:51+00:00

restore_common() was shared between restore and thaw callbacks.  With
thaw gone, we don't need restore_common() anymore.

Signed-off-by: Amit Shah

virtio: drop thaw PM operation

2012-03-31T02:39:50+00:00

The thaw operation was used by the balloon driver, but after the last
commit there's no reason to have separate thaw and restore callbacks.

Signed-off-by: Amit Shah

virtio: pci: add PM notification handlers for restore, freeze, thaw, poweroff

2012-01-12T05:14:44+00:00

Handle thaw, restore and freeze notifications from the PM core.  Expose
these to individual virtio drivers that can quiesce and resume vq
operations.  For drivers not implementing the thaw() method, use the
restore method instead.

These functions also save device-specific data so that the device can be
put in pre-suspend state after resume, and disable and enable the PCI
device in the freeze and resume functions, respectively.

Signed-off-by: Amit Shah 
Signed-off-by: Rusty Russell

virtio: pci: switch to new PM API

2012-01-12T05:14:44+00:00

The older PM API doesn't have a way to get notifications on hibernate
events.  Switch to the newer one that gives us those notifications.

Signed-off-by: Amit Shah 
Signed-off-by: Rusty Russell

virtio: harsher barriers for rpmsg.

2012-01-12T05:14:42+00:00

We were cheating with our barriers; using the smp ones rather than the
real device ones.  That was fine, until rpmsg came along, which is
used to talk to a real device (a non-SMP CPU).

Unfortunately, just putting back the real barriers (reverting
d57ed95d) causes a performance regression on virtio-pci.  In
particular, Amos reports netbench's TCP_RR over virtio_net CPU
utilization increased up to 35% while throughput went down by up to
14%.

By comparison, this branch is in the noise.

Reference: https://lkml.org/lkml/2011/12/11/22

Signed-off-by: Rusty Russell

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2011-12-02T18:49:21+00:00

virtio-pci: make reset operation safer

2011-11-24T02:34:48+00:00

virtio pci device reset actually just does an I/O
write, which in PCI is really posted, that is it
can complete on CPU before the device has received it.

Further, interrupts might have been pending on
another CPU, so device callback might get invoked after reset.

This conflicts with how drivers use reset, which is typically:
	reset
	unregister
a callback running after reset completed can race with
unregister, potentially leading to use after free bugs.

Fix by flushing out the write, and flushing pending interrupts.

This assumes that device is never reset from
its vq/config callbacks, or in parallel with being
added/removed, document this assumption.

Signed-off-by: Michael S. Tsirkin 
Signed-off-by: Rusty Russell

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2011-11-21T18:50:33+00:00

The forcedeth changes had a conflict with the conversion over
to atomic u64 statistics in net-next.

The libertas cfg.c code had a conflict with the bss reference
counting fix by John Linville in net-next.

Conflicts:
	drivers/net/ethernet/nvidia/forcedeth.c
	drivers/net/wireless/libertas/cfg.c