linux-stable.git/drivers/misc, branch v5.7.11

misc: atmel-ssc: lock with mutex instead of spinlock

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

commit b037d60a3b1d1227609fd858fa34321f41829911 upstream.

Uninterruptible context is not needed in the driver and causes lockdep
warning because of mutex taken in of_alias_get_id(). Convert the lock to
mutex to avoid the issue.

Cc: stable@vger.kernel.org
Fixes: 099343c64e16 ("ARM: at91: atmel-ssc: add device tree support")
Signed-off-by: Michał Mirosław 
Link: https://lore.kernel.org/r/50f0d7fa107f318296afb49477c3571e4d6978c5.1592998403.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Greg Kroah-Hartman

mei: bus: don't clean driver pointer

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

commit e852c2c251ed9c23ae6e3efebc5ec49adb504207 upstream.

It's not needed to set driver to NULL in mei_cl_device_remove()
which is bus_type remove() handler as this is done anyway
in __device_release_driver().

Actually this is causing an endless loop in driver_detach()
on ubuntu patched kernel, while removing (rmmod) the mei_hdcp module.
The reason list_empty(&drv->p->klist_devices.k_list) is always not-empty.
as the check is always true in  __device_release_driver()
	if (dev->driver != drv)
		return;

The non upstream patch is causing this behavior, titled:
'vfio -- release device lock before userspace requests'

Nevertheless the fix is correct also for the upstream.

Link: https://patchwork.ozlabs.org/project/ubuntu-kernel/patch/20180912085046.3401-2-apw@canonical.com/
Cc: 
Cc: Andy Whitcroft 
Signed-off-by: Alexander Usyskin 
Signed-off-by: Tomas Winkler 
Link: https://lore.kernel.org/r/20200628225359.2185929-1-tomas.winkler@intel.com
Signed-off-by: Greg Kroah-Hartman

habanalabs: Align protection bits configuration of all TPCs

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

commit 79c823c57e69d9e584a5ee4ee6406eb3854393ae upstream.

Align the protection bits configuration of all TPC cores to be as of TPC
core 0.

Fixes: a513f9a7eca5 ("habanalabs: make tpc registers secured")

Signed-off-by: Tomer Tayar 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
Signed-off-by: Greg Kroah-Hartman

mei: me: add tiger lake point device ids for H platforms.

2020-06-30T19:35:54+00:00

commit 8c289ea064165237891a7b4be77b74d5cba8fa99 upstream.

Add Tiger Lake device ids H for HECI1.
TGH_H is also used in Tatlow SPS platform we need to
disable the mei interface there.

Cc: 
Signed-off-by: Alexander Usyskin 
Signed-off-by: Tomas Winkler 
Link: https://lore.kernel.org/r/20200619165121.2145330-7-tomas.winkler@intel.com
Signed-off-by: Greg Kroah-Hartman

mei: me: disable mei interface on Mehlow server platforms

2020-06-30T19:35:54+00:00

commit f76d77f50b343bc7f7d01e4c2771d43fb074f617 upstream.

For SPS firmware versions 5.0 and newer the way detection has changed.
The detection is done now via PCI_CFG_HFS_3 register.
To prevent conflict the previous method will get sps_4 suffix
Disable both CNP_H and CNP_H_3 interfaces. CNP_H_3 requires
a separate configuration as it doesn't support DMA.

Cc: 
Signed-off-by: Tomas Winkler 
Link: https://lore.kernel.org/r/20200619165121.2145330-1-tomas.winkler@intel.com
Signed-off-by: Greg Kroah-Hartman

misc: xilinx-sdfec: improve get_user_pages_fast() error handling

2020-06-24T15:48:58+00:00

[ Upstream commit 57343d51613227373759f5b0f2eede257fd4b82e ]

This fixes the case of get_user_pages_fast() returning a -errno.
The result needs to be stored in a signed integer. And for safe
signed/unsigned comparisons, it's best to keep everything signed.
And get_user_pages_fast() also expects a signed value for number
of pages to pin.

Therefore, change most relevant variables, from u32 to int. Leave
"n" unsigned, for convenience in checking for overflow. And provide
a WARN_ON_ONCE() and early return, if overflow occurs.

Also, as long as we're tidying up: rename the page array from page,
to pages, in order to match the conventions used in most other call
sites.

Fixes: 20ec628e8007e ("misc: xilinx_sdfec: Add ability to configure LDPC")
Cc: Derek Kiernan 
Cc: Dragan Cvetic 
Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Cc: Michal Simek 
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: John Hubbard 
Link: https://lore.kernel.org/r/20200527012628.1100649-2-jhubbard@nvidia.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

habanalabs: increase timeout during reset

2020-06-24T15:48:47+00:00

[ Upstream commit 7a65ee046b2238e053f6ebb610e1a082cfc49490 ]

When doing training, the DL framework (e.g. tensorflow) performs hundreds
of thousands of memory allocations and mappings. In case the driver needs
to perform hard-reset during training, the driver kills the application and
unmaps all those memory allocations. Unfortunately, because of that large
amount of mappings, the driver isn't able to do that in the current timeout
(5 seconds). Therefore, increase the timeout significantly to 30 seconds
to avoid situation where the driver resets the device with active mappings,
which sometime can cause a kernel bug.

BTW, it doesn't mean we will spend all the 30 seconds because the reset
thread checks every one second if the unmap operation is done.

Reviewed-by: Omer Shpigelman 
Signed-off-by: Oded Gabbay 
Signed-off-by: Sasha Levin

habanalabs: don't allow hard reset with open processes

2020-06-24T15:48:26+00:00

[ Upstream commit 36fafe87edd636292a4ed6a3af9608f2c7d0d0fb ]

When the MMU is heavily used by the engines, unmapping might take a lot of
time due to a full MMU cache invalidation done as part of the unmap flow.
Hence we might not be able to kill all open processes before going to hard
reset the device, as it involves unmapping of all user memory.
In case of a failure in killing all open processes, we should stop the
hard reset flow as it might lead to a kernel crash - one thread (killing
of a process) is updating MMU structures that other thread (hard reset) is
freeing.
Stopping a hard reset flow leaves the device as nonoperational and the
user can then initiate a hard reset via sysfs to reinitialize the device.

Signed-off-by: Omer Shpigelman 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
Signed-off-by: Sasha Levin

misc: fastrpc: fix potential fastrpc_invoke_ctx leak

2020-06-24T15:48:23+00:00

[ Upstream commit 74003385cf716f1b88cc7753ca282f5493f204a2 ]

fastrpc_invoke_ctx can have refcount of 2 in error path where
rpmsg_send() fails to send invoke message. decrement the refcount
properly in the error path to fix this leak.

This also fixes below static checker warning:

drivers/misc/fastrpc.c:990 fastrpc_internal_invoke()
warn: 'ctx->refcount.refcount.ref.counter' not decremented on lines: 990.

Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context")
Reported-by: Dan Carpenter 
Signed-off-by: Srinivas Kandagatla 
Reviewed-by: Bjorn Andersson 
Link: https://lore.kernel.org/r/20200512110930.2550-1-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

misc: fastrpc: Fix an incomplete memory release in fastrpc_rpmsg_probe()

2020-06-24T15:48:23+00:00

[ Upstream commit 0978de9fc7335c73934ab8fac189fb4cb3f23191 ]

fastrpc_channel_ctx is not freed if misc_register() fails, this would
lead to a memory leak. Fix this leak by adding kfree in misc_register()
error path.

Fixes: 278d56f970ae ("misc: fastrpc: Reference count channel context")
Signed-off-by: Srinivas Kandagatla 
Reviewed-by: Bjorn Andersson 
Link: https://lore.kernel.org/r/20200511162722.2552-1-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin