BMC/Intel-BMC/linux.git/drivers/char, branch dev-5.7

Merge tag 'v5.7.12' into dev-5.7

2020-08-04T07:58:36+00:00

This is the 5.7.12 stable release Signed-off-by: Joel Stanley

/dev/mem: Add missing memory barriers for devmem_inode

2020-07-29T08:19:57+00:00

commit b34e7e298d7a5ed76b3aa327c240c29f1ef6dd22 upstream. WRITE_ONCE() isn't the correct way to publish a pointer to a data structure, since it doesn't include a write memory barrier. Therefore other tasks may see that the pointer has been set but not see that the pointed-to memory has finished being initialized yet. Instead a primitive with "release" semantics is needed. Use smp_store_release() for this. The use of READ_ONCE() on the read side is still potentially correct if there's no control dependency, i.e. if all memory being "published" is transitively reachable via the pointer itself. But this pairing is somewhat confusing and error-prone. So just upgrade the read side to smp_load_acquire() so that it clearly pairs with smp_store_release(). Cc: Arnd Bergmann Cc: Ingo Molnar Cc: Kees Cook Cc: Matthew Wilcox Cc: Russell King Cc: Andrew Morton Fixes: 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims the region") Signed-off-by: Eric Biggers Cc: stable Acked-by: Dan Williams Link: https://lore.kernel.org/r/20200716060553.24618-1-ebiggers@kernel.org Signed-off-by: Greg Kroah-Hartman

Merge tag 'v5.7.10' into dev-5.7

2020-07-22T09:35:53+00:00

This is the 5.7.10 stable release Signed-off-by: Joel Stanley

virtio: virtio_console: add missing MODULE_DEVICE_TABLE() for rproc serial

2020-07-22T07:34:19+00:00

commit 897c44f0bae574c5fb318c759b060bebf9dd6013 upstream. rproc_serial_id_table lacks an exposure to module devicetable, so when remoteproc firmware requests VIRTIO_ID_RPROC_SERIAL, no uevent is generated and no module autoloading occurs. Add missing MODULE_DEVICE_TABLE() annotation and move the existing one for VIRTIO_ID_CONSOLE right to the table itself. Fixes: 1b6370463e88 ("virtio_console: Add support for remoteproc serial") Cc: # v3.8+ Signed-off-by: Alexander Lobakin Reviewed-by: Amit Shah Link: https://lore.kernel.org/r/x7C_CbeJtoGMy258nwAXASYz3xgFMFpyzmUvOyZzRnQrgWCREBjaqBOpAUS7ol4NnZYvSVwmTsCG0Ohyfvta-ygw6HMHcoeKK0C3QFiAO_Q=@pm.me Signed-off-by: Greg Kroah-Hartman

tpm_tis: extra chip->ops check on error path in tpm_tis_core_init

2020-07-22T07:34:00+00:00

[ Upstream commit ccf6fb858e17a8f8a914a1c6444d277cfedfeae6 ] Found by smatch: drivers/char/tpm/tpm_tis_core.c:1088 tpm_tis_core_init() warn: variable dereferenced before check 'chip->ops' (see line 979) 'chip->ops' is assigned in the beginning of function in tpmm_chip_alloc->tpm_chip_alloc and is used before first possible goto to error path. Signed-off-by: Vasily Averin Reviewed-by: Jerry Snitselaar Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin

Merge tag 'v5.7.9' into dev-5.7

2020-07-21T01:02:24+00:00

This is the 5.7.9 stable release Signed-off-by: Joel Stanley

tpm: ibmvtpm: Wait for ready buffer before probing for TPM2 attributes

2020-07-09T07:39:35+00:00

[ Upstream commit 72d0556dca39f45eca6c4c085e9eb0fc70aec025 ] The tpm2_get_cc_attrs_tbl() call will result in TPM commands being issued, which will need the use of the internal command/response buffer. But, we're issuing this *before* we've waited to make sure that buffer is allocated. This can result in intermittent failures to probe if the hypervisor / TPM implementation doesn't respond quickly enough. I find it fails almost every time with an 8 vcpu guest under KVM with software emulated TPM. To fix it, just move the tpm2_get_cc_attrs_tlb() call after the existing code to wait for initialization, which will ensure the buffer is allocated. Fixes: 18b3670d79ae9 ("tpm: ibmvtpm: Add support for TPM2") Signed-off-by: David Gibson Reviewed-by: Jerry Snitselaar Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin

tpm: Fix TIS locality timeout problems

2020-07-09T07:39:31+00:00

commit 7862840219058436b80029a0263fd1ef065fb1b3 upstream. It has been reported that some TIS based TPMs are giving unexpected errors when using the O_NONBLOCK path of the TPM device. The problem is that some TPMs don't like it when you get and then relinquish a locality (as the tpm_try_get_ops()/tpm_put_ops() pair does) without sending a command. This currently happens all the time in the O_NONBLOCK write path. Fix this by moving the tpm_try_get_ops() further down the code to after the O_NONBLOCK determination is made. This is safe because the priv->buffer_mutex still protects the priv state being modified. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206275 Fixes: d23d12484307 ("tpm: fix invalid locking in NONBLOCKING mode") Reported-by: Mario Limonciello Tested-by: Alex Guzman Cc: stable@vger.kernel.org Reviewed-by: Jerry Snitselaar Signed-off-by: James Bottomley Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman

Merge tag 'v5.7.7' into dev-5.7

2020-07-08T05:41:18+00:00

Linux 5.7.7 Signed-off-by: Joel Stanley

ipmi: aspeed-g6: Add compatible strings

2020-07-08T04:32:02+00:00

The AST2600 SoC contains the same IPMI (BT/KCS) devices as the AST2500. OpenBMC-Staging-Count: 3 Reviewed-by: Andrew Jeffery Signed-off-by: Brad Bishop Signed-off-by: Joel Stanley