summaryrefslogtreecommitdiffstats
path: root/drivers/input/ff-memless.c
diff options
context:
space:
mode:
authorUma Shankar <uma.shankar@intel.com>2018-08-07 21:15:35 +0530
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2019-11-12 19:21:27 +0100
commit011b7173cbdbd1a5f1826656693ea51516f15dc1 (patch)
treeb74c83f1d03e5c2e8a05c81772657ad370622cdc /drivers/input/ff-memless.c
parenta7bda639a17fe92b66b8bb28e81b558cb8678c85 (diff)
downloadlinux-stable-011b7173cbdbd1a5f1826656693ea51516f15dc1.tar.gz
linux-stable-011b7173cbdbd1a5f1826656693ea51516f15dc1.tar.bz2
linux-stable-011b7173cbdbd1a5f1826656693ea51516f15dc1.zip
drm/i915: Lower RM timeout to avoid DSI hard hangs
commit 1d85a299c4db57c55e0229615132c964d17aa765 upstream. In BXT/APL, device 2 MMIO reads from MIPI controller requires its PLL to be turned ON. When MIPI PLL is turned off (MIPI Display is not active or connected), and someone (host or GT engine) tries to read MIPI registers, it causes hard hang. This is a hardware restriction or limitation. Driver by itself doesn't read MIPI registers when MIPI display is off. But any userspace application can submit unprivileged batch buffer for execution. In that batch buffer there can be mmio reads. And these reads are allowed even for unprivileged applications. If these register reads are for MIPI DSI controller and MIPI display is not active during that time, then the MMIO read operation causes system hard hang and only way to recover is hard reboot. A genuine process/application won't submit batch buffer like this and doesn't cause any issue. But on a compromised system, a malign userspace process/app can generate such batch buffer and can trigger system hard hang (denial of service attack). The fix is to lower the internal MMIO timeout value to an optimum value of 950us as recommended by hardware team. If the timeout is beyond 1ms (which will hit for any value we choose if MMIO READ on a DSI specific register is performed without PLL ON), it causes the system hang. But if the timeout value is lower than it will be below the threshold (even if timeout happens) and system will not get into a hung state. This will avoid a system hang without losing any programming or GT interrupts, taking the worst case of lowest CDCLK frequency and early DC5 abort into account. Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'drivers/input/ff-memless.c')
0 files changed, 0 insertions, 0 deletions