This adds ACPI support for APM X-Gene RNG unit.
Signed-off-by: NFeng Kan <fkan@apm.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This adds a driver for random number generator present on Broadcom
IPROC devices.
Reviewed-by: NRay Jui <rjui@broadcom.com>
Signed-off-by: NScott Branden <sbranden@broadcom.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Simplify the driver's probe function and error handling by using the
device managed allocators, while at it, drop the redundant "out of
memory" messages since these are already printed by the allocator.
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

arch/mips/include/asm/mach-bcm63xx/bcm63xx_regs.h contains the register
definitions for this random number generator block, incorporate these
register definitions directly into the bcm63xx-rng driver so we do not
rely on this header to be provided.
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

bcm_{readl,writel} macros expand to __raw_{readl,writel}, use these
directly such that we do not rely on the platform to provide these for
us. As a result, we no longer use bcm63xx_io.h, so remove that inclusion
too.
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

makes code look a bit prettier.

Cc: linux-crypto@vger.kernel.org.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

makes code look a bit prettier.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

We always do hwrng_init in set_current_rng.  In fact, our current
reference count system relies on this.  So make this explicit by
moving hwrng_init into set_current_rng.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Rather than having callers of set_current_rng call drop_current_rng,
we can do it directly in set_current_rng.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Currently we only register the device when a valid RNG is added.
However the way it's done is buggy because we test whether there
is a current RNG to determine whether we need to register.  As
the current RNG may be missing due to a reinitialisation error
this can lead to a reregistration of the device.

As the device already has to handle a NULL current RNG anyway,
let's just register the device always and remove the complexity.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The kref solution is still buggy because we were only focusing
on the register/unregister race.  The same race affects the
setting of current_rng through sysfs.

This patch fixes it by using kref_get_unless_zero.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

There is no point in doing a manual completion for cleanup_done
when struct completion fits in perfectly.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Another interesting anti-pattern.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Interesting anti-pattern.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The previous patch added one potential problem: we can still be
reading from a hwrng when it's unregistered.  Add a wait for zero
in the hwrng_unregister path.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NAmos Kong <akong@redhat.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

current_rng holds one reference, and we bump it every time we want
to do a read from it.

This means we only hold the rng_mutex to grab or drop a reference,
so accessing /sys/devices/virtual/misc/hw_random/rng_current doesn't
block on read of /dev/hwrng.

Using a kref is overkill (we're always under the rng_mutex), but
a standard pattern.

This also solves the problem that the hwrng_fillfn thread was
accessing current_rng without a lock, which could change (eg. to NULL)
underneath it.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NAmos Kong <akong@redhat.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

In next patch, we use reference counting for each struct hwrng,
changing reference count also needs to take mutex_lock. Before
releasing the lock, if we try to stop a kthread that waits to
take the lock to reduce the referencing count, deadlock will
occur.
Signed-off-by: NAmos Kong <akong@redhat.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

There's currently a big lock around everything, and it means that we
can't query sysfs (eg /sys/devices/virtual/misc/hw_random/rng_current)
while the rng is reading.  This is a real problem when the rng is slow,
or blocked (eg. virtio_rng with qemu's default /dev/random backend)

This doesn't help (it leaves the current lock untouched), just adds a
lock to protect the read function and the static buffers, in preparation
for transition.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

CONFIG_PM is defined as the alternative of CONFIG_PM_RUNTIME and
CONFIG_PM_SLEEP, so it can be used instead of that.

Besides, after commit b2b49ccb (PM: Kconfig: Set PM_RUNTIME if
PM_SLEEP is selected) PM_RUNTIME is always set if PM is set, so
using the alternative isn't even necessary.

Use CONFIG_PM instead of it in drivers/char/hw_random/exynos-rng.c.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>

Add DT support.

Make the driver depend on CONFIG_OF as at91sam9g45 was the only SoC making
use of the TRNG block and this SoC is now fully migrated to DT.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: NPeter Korsgaard <peter@korsgaard.com>
Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Use clk_prepare_enable/_disable_unprepare instead of clk_enable/disable
to work properly with the CCF.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: NPeter Korsgaard <peter@korsgaard.com>
Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The add_early_randomness() function in drivers/char/hw_random/core.c passes
a 16-byte buffer to pseries_rng_data_read(). Unfortunately, plpar_hcall()
returns four 64-bit values and trashes 16 bytes on the stack.

This bug has been lying around for a long time. It got unveiled by:

commit d3cc7996
Author: Amit Shah <amit.shah@redhat.com>
Date:   Thu Jul 10 15:42:34 2014 +0530

    hwrng: fetch randomness only after device init

It may trig a oops while loading or unloading the pseries-rng module for both
PowerVM and PowerKVM guests.

This patch does two things:
- pass an intermediate well sized buffer to plpar_hcall(). This is acceptalbe
  since we're not on a hot path.
- move to the new read API so that we know the return buffer size for sure.

Cc: stable@vger.kernel.org
Signed-off-by: NGreg Kurz <gkurz@linux.vnet.ibm.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The buf is used to hold the list of hwrng devices registered.
The old code ensures we don't walk off the end of buf as we
fill it, but it's unnecessarily complicated and thus difficult
to maintain. Simplify it by using strlcat.
Signed-off-by: NRickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Reviewed-by: NJason Cooper <jason@lakedaemon.net>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

A platform_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Code like
	vi->vq = NULL;
	kfree(vi)
does not make sense.

Clean it up, use goto error labels for cleanup.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

as pr_* macros are more preffered over printk, so printk replaced with corresponding pr_* macros
Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Before we really unregister the hwrng device, reading will get stuck if
the virtio device is reset. We should return error for reading when we
start to remove the device.
Signed-off-by: NAmos Kong <akong@redhat.com>
Reviewed-by: NAmit Shah <amit.shah@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

When we try to hot-remove a busy virtio-rng device from QEMU monitor,
the device can't be hot-removed. Because virtio-rng driver hangs at
wait_for_completion_killable().

This patch exits the waiting by completing have_data completion before
unregistering, resets data_avail to avoid the hwrng core use wrong
buffer bytes.
Signed-off-by: NAmos Kong <akong@redhat.com>
Reviewed-by: NAmit Shah <amit.shah@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

This adds the APM X-Gene SoC RNG support.
Signed-off-by: NFeng Kan <fkan@apm.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The khwrngd thread is started when a hwrng device of sufficient
quality is registered.  The virtio-rng device is backed by the
hypervisor, and we trust the hypervisor to provide real entropy.

A malicious or badly-implemented hypervisor is a scenario that's
irrelevant -- such a setup is bound to cause all sorts of badness, and a
compromised hwrng is the least of the user's worries.

Given this, we might as well assume that the quality of randomness we
receive is perfectly trustworthy.  Hence, we use 100% for the factor,
indicating maximum confidence in the source.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Reviewed-by: NH. Peter Anvin <hpa@linux.intel.com>
Reviewed-by: NAmos Kong <akong@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

rng_get_data() returns the number of bytes read from the hardware.
The entropy argument to add_hwgenerator_randomness() is passed
directly to credit_entropy_bits() so we should be passing the
number of bits, not bytes here.

Fixes: be4000bc "hwrng: create filler thread"
Acked-by: NTorsten Duwe <duwe@suse.de>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>

This reverts commit e052dbf5.

Now that we use the virtio ->scan() function to register with the hwrng
core, we will not get read requests till probe is successfully finished.

So revert the workaround we had in place to refuse read requests while
we were not yet setup completely.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

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
host.  The revert follows in the next commit.

There's a slight behaviour change here on unsuccessful hwrng_register().
Previously, when hwrng_register() failed, the probe() routine would
fail, and the vqs would be torn down, and driver would be marked not
initialized.  Now, the vqs will remain initialized, driver would be
marked initialized as well, but won't be available in the list of RNGs
available to hwrng core.  To fix the failures, the procedure remains the
same, i.e. unload and re-load the module, and hope things succeed the
next time around.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Re-arrange the elements of the virtrng_info struct to pack it better.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

vdev is unused in struct virtrng_info, remove it.

CC: Amos Kong <akong@redhat.com>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Signed-off-by: NTorsten Duwe <duwe@suse.de>
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>

This patch introduces a derating factor to struct hwrng for
the random bits going into the kernel input pool, and a common
default derating for drivers which do not specify one.
Signed-off-by: NTorsten Duwe <duwe@suse.de>
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
Acked-by: NH. Peter Anvin <hpa@zytor.com>

This can be viewed as the in-kernel equivalent of hwrngd;
like FUSE it is a good thing to have a mechanism in user land,
but for some reasons (simplicity, secrecy, integrity, speed)
it may be better to have it in kernel space.

This patch creates a thread once a hwrng registers, and uses
the previously established add_hwgenerator_randomness() to feed
its data to the input pool as long as needed. A derating factor
is used to bias the entropy estimation and to disable this
mechanism entirely when set to zero.
Signed-off-by: NTorsten Duwe <duwe@suse.de>
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
Acked-by: NH. Peter Anvin <hpa@zytor.com>

The hwrng core asks for random data in the hwrng_register() call itself
from commit d9e79726.  This doesn't play well with virtio -- the
DRIVER_OK bit is only set by virtio core on a successful probe, and
we're not yet out of our probe routine when this call is made.  This
causes the host to not acknowledge any requests we put in the virtqueue,
and the insmod or kernel boot process just waits for data to arrive from
the host, which never happens.

CC: Kees Cook <keescook@chromium.org>
CC: Jason Cooper <jason@lakedaemon.net>
CC: Herbert Xu <herbert@gondor.apana.org.au>
CC: <stable@vger.kernel.org> # For v3.15+
Reviewed-by: NJason Cooper <jason@lakedaemon.net>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Commit d9e79726 "hwrng: add randomness to system from rng sources"
added a call to rng_get_data() from the hwrng_register() function.
However, some rng devices need initialization before data can be read
from them.

This commit makes the call to rng_get_data() depend on no init fn
pointer being registered by the device.  If an init function is
registered, this call is made after device init.

CC: Kees Cook <keescook@chromium.org>
CC: Jason Cooper <jason@lakedaemon.net>
CC: Herbert Xu <herbert@gondor.apana.org.au>
CC: <stable@vger.kernel.org> # For v3.15+
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Reviewed-by: NJason Cooper <jason@lakedaemon.net>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>