linux/drivers/misc, branch v5.8

habanalabs: prevent possible out-of-bounds array access

2020-07-19T05:15:36Z

Queue index is received from the user. Therefore, we must validate it before using it to access the queue props array. Signed-off-by: Oded Gabbay Reviewed-by: Tomer Tayar

habanalabs: set 4s timeout for message to device CPU

2020-07-10T16:53:03Z

We see that sometimes the CPU in GOYA and GAUDI is occupied by the power/thermal loop and can't answer requests from the driver fast enough. Therefore, to avoid false notifications on timeouts, increase the timeout to 4 seconds on each message sent to the device CPU. Signed-off-by: Oded Gabbay Reviewed-by: Tomer Tayar

habanalabs: set clock gating per engine

2020-07-10T16:53:03Z

For debugging purposes, we need to allow the root user better control of the clock gating feature of the DMA and compute engines. Therefore, change the clock gating debugfs interface to be bitmask instead of true/false. Each bit represents a different engine, according to gaudi_engine_id enum. See debugfs documentation for more details. Signed-off-by: Oded Gabbay Reviewed-by: Omer Shpigelman

habanalabs: block WREG_BULK packet on PDMA

2020-07-10T16:53:03Z

WREG_BULK is a special packet that has a variable length. Therefore, we can't parse it when validating CBs that go to the PCI DMA queue. In case the user needs to use it, it can put multiple WREG32 packets instead. Signed-off-by: Oded Gabbay Reviewed-by: Omer Shpigelman

mei: bus: don't clean driver pointer

2020-06-29T17:10:51Z

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

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

2020-06-29T17:10:51Z

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

habanalabs: increase h/w timer when checking idle

2020-06-24T09:35:23Z

In GAUDI the current timer value for the hardware to check if it is in IDLE state is too low. As a result, there are occasions where the H/W wrongly reports it is not IDLE. The driver checks that before submitting work on behalf of the driver during initialization, so a false report might cause the driver to fail during device initialization. Signed-off-by: Omer Shpigelman Signed-off-by: Oded Gabbay

habanalabs: Correct handling when failing to enqueue CB

2020-06-24T06:09:10Z

The fence release flow is different if the CS was never submitted. In that case, we don't have an hw_sob object attached that we need to "put". While if the CS was aborted, we do need to "put" the hw_sob. Signed-off-by: Ofir Bitton Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay

habanalabs: increase GAUDI QMAN ARB WDT timeout

2020-06-24T06:09:10Z

The current timeout is too low for some of the workloads and we see false errors as a result. Reviewed-by: Tomer Tayar Signed-off-by: Oded Gabbay

habanalabs: rename mmu_write() to mmu_asid_va_write()

2020-06-24T06:09:10Z

The function name conflicts with a static inline function in arch/m68k/include/asm/mcfmmu.h Reported-by: kernel test robot Reviewed-by: Tomer Tayar Signed-off-by: Oded Gabbay