linux-stable.git/drivers/char, branch v5.4.13

tpm: Handle negative priv->response_len in tpm_common_read()

2020-01-14T19:08:21+00:00

commit a430e67d9a2c62a8c7b315b99e74de02018d0a96 upstream.

The priv->response_length can hold the size of an response or an negative
error code, and the tpm_common_read() needs to handle both cases correctly.
Changed the type of response_length to signed and accounted for negative
value in tpm_common_read().

Cc: stable@vger.kernel.org
Fixes: d23d12484307 ("tpm: fix invalid locking in NONBLOCKING mode")
Reported-by: Laura Abbott 
Signed-off-by: Tadeusz Struk 
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: Greg Kroah-Hartman

tpm: Revert "tpm_tis_core: Turn on the TPM before probing IRQ's"

2020-01-14T19:08:21+00:00

commit aa4a63dd981682b1742baa01237036e48bc11923 upstream.

There has been a bunch of reports (one from kernel bugzilla linked)
reporting that when this commit is applied it causes on some machines
boot freezes.

Unfortunately hardware where this commit causes a failure is not widely
available (only one I'm aware is Lenovo T490), which means we cannot
predict yet how long it will take to properly fix tpm_tis interrupt
probing.

Thus, the least worst short term action is to revert the code to the
state before this commit. In long term we need fix the tpm_tis probing
code to work on machines that Stefan's fix was supposed to fix.

Fixes: 21df4a8b6018 ("tpm_tis: reserve chip for duration of tpm_tis_core_init")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=205935
Cc: stable@vger.kernel.org
Cc: Jerry Snitselaar 
Cc: Dan Williams 
Tested-by: Dan Williams 
Tested-by: Xiaoping Zhou 
Signed-off-by: Stefan Berger 
Reported-by: Jerry Snitselaar 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: Greg Kroah-Hartman

tpm: Revert "tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for interrupts"

2020-01-14T19:08:21+00:00

commit dda8b2af395b2ed508e2ef314ae32e122841b447 upstream.

There has been a bunch of reports (one from kernel bugzilla linked)
reporting that when this commit is applied it causes on some machines
boot freezes.

Unfortunately hardware where this commit causes a failure is not widely
available (only one I'm aware is Lenovo T490), which means we cannot
predict yet how long it will take to properly fix tpm_tis interrupt
probing.

Thus, the least worst short term action is to revert the code to the
state before this commit. In long term we need fix the tpm_tis probing
code to work on machines that Stefan's fix was supposed to fix.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=205935
Fixes: 1ea32c83c699 ("tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for interrupts")
Cc: stable@vger.kernel.org
Cc: Jerry Snitselaar 
Cc: Dan Williams 
Tested-by: Dan Williams 
Tested-by: Xiaoping Zhou 
Signed-off-by: Stefan Berger 
Reported-by: Jerry Snitselaar 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: Greg Kroah-Hartman

tpm: Revert "tpm_tis: reserve chip for duration of tpm_tis_core_init"

2020-01-14T19:08:20+00:00

commit 9550f210492c6f88415709002f42a9d15c0e6231 upstream.

Revert a commit, which was included in Linux v5.5-rc3 because it did not
properly fix the issues it was supposed to fix.

Fixes: 21df4a8b6018 ("tpm_tis: reserve chip for duration of tpm_tis_core_init")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=205935
Cc: stable@vger.kernel.org
Cc: Jerry Snitselaar 
Cc: Dan Williams 
Tested-by: Dan Williams 
Tested-by: Xiaoping Zhou 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: Greg Kroah-Hartman

tpm/tpm_ftpm_tee: add shutdown call back

2020-01-12T11:21:41+00:00

[ Upstream commit 1760eb689ed68c6746744aff2092bff57c78d907 ]

Add shutdown call back to close existing session with fTPM TA
to support kexec scenario.

Add parentheses to function names in comments as specified in kdoc.

Signed-off-by: Thirupathaiah Annapureddy 
Signed-off-by: Pavel Tatashin 
Reviewed-by: Jarkko Sakkinen 
Tested-by: Sasha Levin 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: Sasha Levin

tpm: fix invalid locking in NONBLOCKING mode

2019-12-31T15:45:52+00:00

commit d23d12484307b40eea549b8a858f5fffad913897 upstream.

When an application sends TPM commands in NONBLOCKING mode
the driver holds chip->tpm_mutex returning from write(),
which triggers: "WARNING: lock held when returning to user space".
To fix this issue the driver needs to release the mutex before
returning and acquire it again in tpm_dev_async_work() before
sending the command.

Cc: stable@vger.kernel.org
Fixes: 9e1b74a63f776 (tpm: add support for nonblocking operation)
Reported-by: Jeffrin Jose T 
Tested-by: Jeffrin Jose T 
Signed-off-by: Tadeusz Struk 
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: Greg Kroah-Hartman

tpm_tis: reserve chip for duration of tpm_tis_core_init

2019-12-31T15:45:52+00:00

commit 21df4a8b6018b842d4db181a8b24166006bad3cd upstream.

Instead of repeatedly calling tpm_chip_start/tpm_chip_stop when
issuing commands to the tpm during initialization, just reserve the
chip after wait_startup, and release it when we are ready to call
tpm_chip_register.

Cc: Christian Bundy 
Cc: Dan Williams 
Cc: Peter Huewe 
Cc: Jarkko Sakkinen 
Cc: Jason Gunthorpe 
Cc: Stefan Berger 
Cc: stable@vger.kernel.org
Cc: linux-integrity@vger.kernel.org
Fixes: a3fbfae82b4c ("tpm: take TPM chip power gating out of tpm_transmit()")
Fixes: 5b359c7c4372 ("tpm_tis_core: Turn on the TPM before probing IRQ's")
Suggested-by: Jarkko Sakkinen 
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jerry Snitselaar 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: Greg Kroah-Hartman

ipmi: Don't allow device module unload when in use

2019-12-31T15:44:14+00:00

[ Upstream commit cbb79863fc3175ed5ac506465948b02a893a8235 ]

If something has the IPMI driver open, don't allow the device
module to be unloaded.  Before it would unload and the user would
get errors on use.

This change is made on user request, and it makes it consistent
with the I2C driver, which has the same behavior.

It does change things a little bit with respect to kernel users.
If the ACPI or IPMI watchdog (or any other kernel user) has
created a user, then the device module cannot be unloaded.  Before
it could be unloaded,

This does not affect hot-plug.  If the device goes away (it's on
something removable that is removed or is hot-removed via sysfs)
then it still behaves as it did before.

Reported-by: tony camuso 
Signed-off-by: Corey Minyard 
Tested-by: tony camuso 
Signed-off-by: Sasha Levin

hwrng: omap3-rom - Call clk_disable_unprepare() on exit only if not idled

2019-12-31T15:43:39+00:00

[ Upstream commit eaecce12f5f0d2c35d278e41e1bc4522393861ab ]

When unloading omap3-rom-rng, we'll get the following:

WARNING: CPU: 0 PID: 100 at drivers/clk/clk.c:948 clk_core_disable

This is because the clock may be already disabled by omap3_rom_rng_idle().
Let's fix the issue by checking for rng_idle on exit.

Cc: Aaro Koskinen 
Cc: Adam Ford 
Cc: Pali Rohár 
Cc: Sebastian Reichel 
Cc: Tero Kristo 
Fixes: 1c6b7c2108bd ("hwrng: OMAP3 ROM Random Number Generator support")
Signed-off-by: Tony Lindgren 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin

ppdev: fix PPGETTIME/PPSETTIME ioctls

2019-12-17T18:56:41+00:00

commit 998174042da229e2cf5841f574aba4a743e69650 upstream.

Going through the uses of timeval in the user space API,
I noticed two bugs in ppdev that were introduced in the y2038
conversion:

* The range check was accidentally moved from ppsettime to
  ppgettime

* On sparc64, the microseconds are in the other half of the
  64-bit word.

Fix both, and mark the fix for stable backports.

Cc: stable@vger.kernel.org
Fixes: 3b9ab374a1e6 ("ppdev: convert to y2038 safe")
Signed-off-by: Arnd Bergmann 
Link: https://lore.kernel.org/r/20191108203435.112759-8-arnd@arndb.de
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman