similar to: [PATCH 0/2] virtio: Replace CONFIG_PM with CONFIG_PM_SLEEP

The virtio_pci_freeze/restore are defined under CONFIG_PM but is used by SET_SYSTEM_SLEEP_PM_OPS macro, which is defined under CONFIG_PM_SLEEP. So if CONFIG_PM_SLEEP is not cofigured but CONFIG_PM_RUNTIME is, the following warning message appeared: drivers/virtio/virtio_pci.c:770:12: warning: ?virtio_pci_freeze? defined but not used [-Wunused-function] static int virtio_pci_freeze(struct device

The virtio_pci_freeze/restore are defined under CONFIG_PM but is used by SET_SYSTEM_SLEEP_PM_OPS macro, which is defined under CONFIG_PM_SLEEP. So if CONFIG_PM_SLEEP is not cofigured but CONFIG_PM_RUNTIME is, the following warning message appeared: drivers/virtio/virtio_pci.c:770:12: warning: ?virtio_pci_freeze? defined but not used [-Wunused-function] static int virtio_pci_freeze(struct device

On 09/06/2013 03:20 PM, Amit Shah wrote: > On (Fri) 06 Sep 2013 [10:28:36], Aaron Lu wrote: >> >> The virtio_pci_freeze/restore are defined under CONFIG_PM but is used >> by SET_SYSTEM_SLEEP_PM_OPS macro, which is defined under >> CONFIG_PM_SLEEP. So if CONFIG_PM_SLEEP is not cofigured but >> CONFIG_PM_RUNTIME is, the following warning message appeared: >>

On 09/06/2013 03:20 PM, Amit Shah wrote: > On (Fri) 06 Sep 2013 [10:28:36], Aaron Lu wrote: >> >> The virtio_pci_freeze/restore are defined under CONFIG_PM but is used >> by SET_SYSTEM_SLEEP_PM_OPS macro, which is defined under >> CONFIG_PM_SLEEP. So if CONFIG_PM_SLEEP is not cofigured but >> CONFIG_PM_RUNTIME is, the following warning message appeared: >>

Hi Rusty, These are a few fixes for the virtio-rng driver. These were tested using the not-yet-upstream virtio-rng device patch to qemu: http://thread.gmane.org/gmane.comp.emulators.qemu/152668 Please apply. Amit Shah (5): virtio ids: fix comment for virtio-rng virtio: rng: allow tasks to be killed that are waiting for rng input virtio: rng: don't wait on host when module is going

Hi Rusty, These are a few fixes for the virtio-rng driver. These were tested using the not-yet-upstream virtio-rng device patch to qemu: http://thread.gmane.org/gmane.comp.emulators.qemu/152668 Please apply. Amit Shah (5): virtio ids: fix comment for virtio-rng virtio: rng: allow tasks to be killed that are waiting for rng input virtio: rng: don't wait on host when module is going

v2: - update patch 3 to store the hwrng_register_done bool per-device rather than global - add patch 2 that re-arranges struct elems for better packing. Hi, This series enables virtio-rng to service the early randomness requests made by the hwrng core (patch 3), with Herbert's idea of using the scan routine. Patch 4 reverts the previous restriction, which no longer applies, to not send

v2: - update patch 3 to store the hwrng_register_done bool per-device rather than global - add patch 2 that re-arranges struct elems for better packing. Hi, This series enables virtio-rng to service the early randomness requests made by the hwrng core (patch 3), with Herbert's idea of using the scan routine. Patch 4 reverts the previous restriction, which no longer applies, to not send

Instead of calling hwrng_register() in the probe routing, call it in the scan routine. This ensures that when hwrng_register() is successful, and it requests a few random bytes to seed the kernel's pool at init, we're ready to service that request. This will also enable us to remove the workaround added previously to check whether probe was completed, and only then ask for data from the

Instead of calling hwrng_register() in the probe routing, call it in the scan routine. This ensures that when hwrng_register() is successful, and it requests a few random bytes to seed the kernel's pool at init, we're ready to service that request. This will also enable us to remove the workaround added previously to check whether probe was completed, and only then ask for data from the

Hi, This series enables virtio-rng to service the early randomness requests made by the hwrng core (patch 2), with Herbert's idea of using the scan routine. Patch 3 reverts the previous restriction, which no longer applies, to not send read requests to the host before successful probe. Patch 1 is a minor cleanup. Please review and apply, Amit Shah (3): virtio: rng: remove unused struct

Hi, This series enables virtio-rng to service the early randomness requests made by the hwrng core (patch 2), with Herbert's idea of using the scan routine. Patch 3 reverts the previous restriction, which no longer applies, to not send read requests to the host before successful probe. Patch 1 is a minor cleanup. Please review and apply, Amit Shah (3): virtio: rng: remove unused struct

On 09/06/2013 04:22 PM, Amit Shah wrote: > On (Fri) 06 Sep 2013 [16:20:05], Aaron Lu wrote: >> This patchset replace CONFIG_PM with CONFIG_PM_SLEEP for all virtio >> drivers and virtio pci driver. >> >> With patch 1/2, two compile warnings are eliminated for virtio pci >> driver, and patch 2/2 is a clean up for all virtio drivers as suggested >> by Amit Shah.

On 09/06/2013 04:22 PM, Amit Shah wrote: > On (Fri) 06 Sep 2013 [16:20:05], Aaron Lu wrote: >> This patchset replace CONFIG_PM with CONFIG_PM_SLEEP for all virtio >> drivers and virtio pci driver. >> >> With patch 1/2, two compile warnings are eliminated for virtio pci >> driver, and patch 2/2 is a clean up for all virtio drivers as suggested >> by Amit Shah.

On (Fri) 06 Sep 2013 [10:28:36], Aaron Lu wrote: > > The virtio_pci_freeze/restore are defined under CONFIG_PM but is used > by SET_SYSTEM_SLEEP_PM_OPS macro, which is defined under > CONFIG_PM_SLEEP. So if CONFIG_PM_SLEEP is not cofigured but > CONFIG_PM_RUNTIME is, the following warning message appeared: > > drivers/virtio/virtio_pci.c:770:12: warning: ?virtio_pci_freeze?

On (Fri) 06 Sep 2013 [15:41:36], Aaron Lu wrote: > On 09/06/2013 03:20 PM, Amit Shah wrote: > > On (Fri) 06 Sep 2013 [10:28:36], Aaron Lu wrote: > >> > >> The virtio_pci_freeze/restore are defined under CONFIG_PM but is used > >> by SET_SYSTEM_SLEEP_PM_OPS macro, which is defined under > >> CONFIG_PM_SLEEP. So if CONFIG_PM_SLEEP is not cofigured but

On (Fri) 06 Sep 2013 [10:28:36], Aaron Lu wrote: > > The virtio_pci_freeze/restore are defined under CONFIG_PM but is used > by SET_SYSTEM_SLEEP_PM_OPS macro, which is defined under > CONFIG_PM_SLEEP. So if CONFIG_PM_SLEEP is not cofigured but > CONFIG_PM_RUNTIME is, the following warning message appeared: > > drivers/virtio/virtio_pci.c:770:12: warning: ?virtio_pci_freeze?

Hello, Turns out S3 is not different from S4 for virtio devices: the device is assumed to be reset, so the host and guest state are to be assumed to be out of sync upon resume. We handle the S4 case with exactly the same scenario, so just point the suspend/resume routines to the freeze/restore ones. Once that is done, we also use the PM API's macro to initialise the sleep functions. A

Hello, Turns out S3 is not different from S4 for virtio devices: the device is assumed to be reset, so the host and guest state are to be assumed to be out of sync upon resume. We handle the S4 case with exactly the same scenario, so just point the suspend/resume routines to the freeze/restore ones. Once that is done, we also use the PM API's macro to initialise the sleep functions. A

On Mon, Jul 21, 2014 at 05:15:51PM +0530, Amit Shah wrote: > Instead of calling hwrng_register() in the probe routing, call it in the > scan routine. This ensures that when hwrng_register() is successful, > and it requests a few random bytes to seed the kernel's pool at init, > we're ready to service that request. > > This will also enable us to remove the workaround