linux-toradex.git/drivers/char, branch v3.16.5

Revert "hwrng: virtio - ensure reads happen after successful probe"

2014-10-05T20:41:08+00:00

commit eeec626366ffe558fc3d5685bd2b49a962acf57d upstream.

This reverts commit e052dbf554610e2104c5a7518c4d8374bed701bb.

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: Amit Shah 
Signed-off-by: Rusty Russell 
Signed-off-by: Greg Kroah-Hartman

virtio: rng: delay hwrng_register() till driver is ready

2014-10-05T20:41:08+00:00

commit 5c06273401f2eb7b290cadbae18ee00f8f65e893 upstream.

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: Amit Shah 
Signed-off-by: Rusty Russell 
Signed-off-by: Greg Kroah-Hartman

tpm: Properly clean sysfs entries in error path

2014-09-17T16:21:52+00:00

commit b49e1043c48dac23f64fba684d31c4a96c1ffaa0 upstream.

Properly clean the sysfs entries in the error path

Reported-by: Dmitry Kasatkin 
Signed-off-by: Stefan Berger 
Reviewed-by: Jason Gunthorpe 
Signed-off-by: Peter Huewe 
Signed-off-by: Greg Kroah-Hartman

tpm: Provide a generic means to override the chip returned timeouts

2014-09-17T16:21:52+00:00

commit 8e54caf407b98efa05409e1fee0e5381abd2b088 upstream.

Some Atmel TPMs provide completely wrong timeouts from their
TPM_CAP_PROP_TIS_TIMEOUT query. This patch detects that and returns
new correct values via a DID/VID table in the TIS driver.

Tested on ARM using an AT97SC3204T FW version 37.16

[PHuewe: without this fix these 'broken' Atmel TPMs won't function on
older kernels]
Signed-off-by: "Berg, Christopher" 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Greg Kroah-Hartman 

Signed-off-by: Peter Huewe

tpm: missing tpm_chip_put in tpm_get_random()

2014-09-17T16:21:52+00:00

commit 3e14d83ef94a5806a865b85b513b4e891923c19b upstream.

Regression in 41ab999c. Call to tpm_chip_put is missing. This
will cause TPM device driver not to unload if tmp_get_random()
is called.

Signed-off-by: Jarkko Sakkinen 
Signed-off-by: Peter Huewe 
Signed-off-by: Greg Kroah-Hartman

tpm: Add missing tpm_do_selftest to ST33 I2C driver

2014-09-05T23:36:30+00:00

commit f07a5e9a331045e976a3d317ba43d14859d9407c upstream.

Most device drivers do call 'tpm_do_selftest' which executes a
TPM_ContinueSelfTest. tpm_i2c_stm_st33 is just pointlessly different,
I think it is bug.

These days we have the general assumption that the TPM is usable by
the kernel immediately after the driver is finished, so we can no
longer defer the mandatory self test to userspace.

Reported-by: Richard Marciel 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Peter Huewe 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'random_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random

2014-07-19T06:26:46+00:00

Pull /dev/random fix from Ted Ts'o:
 "Fix a BUG splat found by trinity"

* tag 'random_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random:
  random: check for increase of entropy_count because of signed conversion

Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6

2014-07-19T06:25:54+00:00

Pull crypto fixes from Herbert Xu:
 "This push fixes a boot hang in virt guests when the virtio RNG is
  enabled"

* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
  hwrng: virtio - ensure reads happen after successful probe
  hwrng: fetch randomness only after device init

random: check for increase of entropy_count because of signed conversion

2014-07-19T05:42:13+00:00

The expression entropy_count -= ibytes << (ENTROPY_SHIFT + 3) could
actually increase entropy_count if during assignment of the unsigned
expression on the RHS (mind the -=) we reduce the value modulo
2^width(int) and assign it to entropy_count. Trinity found this.

[ Commit modified by tytso to add an additional safety check for a
  negative entropy_count -- which should never happen, and to also add
  an additional paranoia check to prevent overly large count values to
  be passed into urandom_read().  ]

Reported-by: Dave Jones 
Signed-off-by: Hannes Frederic Sowa 
Signed-off-by: Theodore Ts'o 
Cc: stable@vger.kernel.org

hwrng: virtio - ensure reads happen after successful probe

2014-07-14T12:48:17+00:00

The hwrng core asks for random data in the hwrng_register() call itself
from commit d9e7972619.  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 
CC: Jason Cooper 
CC: Herbert Xu 
CC:  # For v3.15+
Reviewed-by: Jason Cooper 
Signed-off-by: Amit Shah 
Signed-off-by: Herbert Xu