Commit 64f7c698 ("drm/nouveau/fifo: add engine_id hook") replaced
fifo/chang84.c g84_fifo_chan_engine() call with an indirect call of
fifo/g84.c g84_fifo_engine_id(). The G84_FIFO_ENGN_* values returned
from the later g84_fifo_engine_id() are incremented by 1 compared to
the previous g84_fifo_chan_engine() return values.

This is fine either way for most of the code, except this one line
where an engine bit programmed into the hardware is derived from the
return value. Decrement the return value accordingly, otherwise the
wrong engine bit is programmed into the hardware and that leads to
the following failure:
nouveau 0000:01:00.0: gr: 00000030 [ILLEGAL_MTHD ILLEGAL_CLASS] ch 1 [003fbce000 DRM] subc 3 class 0000 mthd 085c data 00000420

On the following hardware:
lspci -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation GT216GLM [Quadro FX 880M] (rev a2)
lspci -ns 01:00.0
01:00.0 0300: 10de:0a3c (rev a2)

Fixes: 64f7c698 ("drm/nouveau/fifo: add engine_id hook")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: <stable@vger.kernel.org> # 5.12+
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Karol Herbst <kherbst@redhat.com>
Cc: Lyude Paul <lyude@redhat.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211007214117.231472-1-marex@denx.deSigned-off-by: Dave Airlie <airlied@redhat.com>

Hyper-V supports a hardware cursor feature. It is not used by Linux VM,
but the Hyper-V host still draws a point as an extra mouse pointer,
which is unwanted, especially when Xorg is running.

The hyperv_fb driver uses synthvid_send_ptr() to hide the unwanted pointer.
When the hyperv_drm driver was developed, the function synthvid_send_ptr()
was not copied from the hyperv_fb driver. Fix the issue by adding the
function into hyperv_drm.

Fixes: 76c56a5a ("drm/hyperv: Add DRM driver for hyperv synthetic video device")
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: Deepak Rawat <drawat.floss@gmail.com>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20210916193644.45650-1-decui@microsoft.comSigned-off-by: Dave Airlie <airlied@redhat.com>

Clamp the fbdev surface size of the available maximumi height to avoid
failing to init console emulation. An example error is shown below.

  bad framebuffer height 2304, should be >= 768 && <= 768
  [drm] Initialized simpledrm 1.0.0 20200625 for simple-framebuffer.0 on minor 0
  simple-framebuffer simple-framebuffer.0: [drm] *ERROR* fbdev: Failed to setup generic emulation (ret=-22)

This is especially a problem with drivers that have very small screen
sizes and cannot over-allocate at all.

v2:
	* reduce warning level (Ville)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: 11e8f5fd ("drm: Add simpledrm driver")
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reported-by: Amanoel Dawod <kernel@amanoeldawod.com>
Reported-by: Zoltán Kővágó <dirty.ice.hu@gmail.com>
Reported-by: Michael Stapelberg <michael+lkml@stapelberg.ch>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Maxime Ripard <maxime@cerno.tech>
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v5.14+
Link: https://patchwork.freedesktop.org/patch/msgid/20211005070355.7680-1-tzimmermann@suse.deSigned-off-by: Dave Airlie <airlied@redhat.com>

In commit e11f5bd8 ("drm: Add support for DP 1.4 Compliance edid
corruption test") the function connector_bad_edid() started assuming
that the memory for the EDID passed to it was big enough to hold
`edid[0x7e] + 1` blocks of data (1 extra for the base block). It
completely ignored the fact that the function was passed `num_blocks`
which indicated how much memory had been allocated for the EDID.

Let's fix this by adding a bounds check.

This is important for handling the case where there's an error in the
first block of the EDID. In that case we will call
connector_bad_edid() without having re-allocated memory based on
`edid[0x7e]`.

Fixes: e11f5bd8 ("drm: Add support for DP 1.4 Compliance edid corruption test")
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211005192905.v2.1.Ib059f9c23c2611cb5a9d760e7d0a700c1295928d@changeidSigned-off-by: Dave Airlie <airlied@redhat.com>

Merge tag 'mediatek-drm-fixes-5.15' of https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-fixes

Mediatek DRM Fixes for Linux 5.15

1. Revert series "CMDQ refinement of Mediatek DRM driver"
Signed-off-by: Dave Airlie <airlied@redhat.com>

From: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20211013235044.5488-1-chunkuang.hu@kernel.org

Merge tag 'drm-intel-fixes-2021-10-14' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes

drm/i915 fixes for v5.15-rc6:
- Fix ACPI object leak
- Fix context leak in user proto-context creation
- Fix missing i915_sw_fence_fini call
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/87zgrbvgls.fsf@intel.com

As per the comment on top of acpi_evaluate_dsm():

| * Evaluate device's _DSM method with specified GUID, revision id and
| * function number. Caller needs to free the returned object.

We should free the returned object of acpi_evaluate_dsm() to avoid memory
leakage. Otherwise the kmemleak splat will be triggered at boot time (if we
compile kernel with CONFIG_DEBUG_TEST_DRIVER_REMOVE=y).

Fixes: 8e55f99c ("drm/i915: Invoke another _DSM to enable MUX on HP Workstation laptops")
Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210906033541.862-1-yuzenghui@huawei.com
(cherry picked from commit 149ac2e7)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Set number of engines before attempting to create contexts so the
function free_engines can clean up properly. Also check return of
alloc_engines for NULL.

v2:
 (Tvrtko)
  - Send as stand alone patch
 (John Harrison)
  - Check for alloc_engines returning NULL
v3:
 (Checkpatch / Tvrtko)
  - Remove braces around single line if statement

Cc: Jason Ekstrand <jason@jlekstrand.net>
Fixes: d4433c76 ("drm/i915/gem: Use the proto-context to handle create parameters (v5)")
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211001155825.6762-1-matthew.brost@intel.com
(cherry picked from commit 84edf537)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

On R-Car D3 and E3, the LVDS encoders provide the pixel clock to the DU,
even when LVDS outputs are not used. For this reason, the rcar-lvds
driver probes successfully on those platforms even if no further bridge
or panel is connected to the LVDS output, in order to provide the
rcar_lvds_clk_enable() and rcar_lvds_clk_disable() functions to the DU
driver.

If an LVDS output isn't connected, trying to create a DRM connector for
the output will fail. Fix this by skipping connector creation in that
case, and also skip creation of the DRM encoder as there's no point in
an encoder without a connector.

Fixes: e9e05694 ("drm: rcar-du: lvds: Convert to DRM panel bridge helper")
Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
(cherry picked from commit 187502af)
Signed-off-by: Dave Airlie <airlied@redhat.com>

* Fix a new crash on dev file close if the dev file was opened when
  GPU is not loaded (such as missing fw in initrd)
* Switch to single drm_sched_entity per priority level per drm_file
  to unbreak multi-context userspace
* Serialize GMU access to fix GMU OOB errors
* Various error path fixes
* A couple integer overflow fixes
* Fix mdp5 cursor plane WARNs
Signed-off-by: Dave Airlie <airlied@redhat.com>
From:   Rob Clark <robdclark@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGtD4u7yyiy+BQLmibUCbn=AdDRu7FrmdViHVx0QrcGf8g@mail.gmail.com

This disables a lock which wasn't enabled and it does not disable
the first lock in the array.

Fixes: 6e0eb52e ("drm/msm/dsi: Parse bus clocks from a list")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20211001123409.GG2283@kiliSigned-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>

Return an error code if msm_dsi_manager_validate_current_config().
Don't return success.

Fixes: 8b03ad30 ("drm/msm/dsi: Use one connector for dual DSI mode")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20211001123308.GF2283@kiliSigned-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>

The downstream driver models this PLL lock check as an if-elseif-else.
The only way to reach the else case where pll_locked=true [1] is by
succeeding both readl_poll_timeout_atomic calls (which return zero on
success) in the if _and_ elseif condition.  Hence both the "lock" and
"ready" bit need to be tested in the SM_READY_STATUS register before
considering the PLL locked and ready to go.

Tested on the Sony Xperia XA2 Ultra (nile-discovery, sdm630).

[1]: https://source.codeaurora.org/quic/la/kernel/msm-4.19/tree/drivers/clk/qcom/mdss/mdss-dsi-pll-14nm-util.c?h=LA.UM.9.2.1.r1-08000-sdm660.0#n302

Fixes: f079f6d9 ("drm/msm/dsi: Add PHY/PLL for 8x96")
Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20210906202552.824598-1-marijn.suijten@somainline.orgSigned-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>

The commit 9f91f22a ("drm/msm/dsi: remove duplicate fields from
dsi_pll_Nnm instances") mistakenly changed registered clock names. While
the platform is in progress of migration to using clock properties in
the dts rather than the global clock names, we should provide backwards
compatibility. Thus restore registerd global clock names.

Fixes: 9f91f22a ("drm/msm/dsi: remove duplicate fields from dsi_pll_Nnm instances")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Link: https://lore.kernel.org/r/20210921162245.1858118-1-dmitry.baryshkov@linaro.orgSigned-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>

Both PINGPONG4 and PINGPONG5 IRQ registers are using the
same address, which is incorrect. PINGPONG4 should use the
register offset 30, and PINGPONG5 should use the register
offset 31 according to the downstream driver.

Fixes: 667e9985 ("drm/msm/dpu: replace IRQ lookup with the data in hw catalog")
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20210819133636.2045766-1-robert.foss@linaro.orgSigned-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>

Since commit 98659487 ("drm/msm: add support to take dpu snapshot")
the following NULL pointer dereference is seen on i.MX53:

[ 3.275493] msm msm: bound 30000000.gpu (ops a3xx_ops)
[ 3.287174] [drm] Initialized msm 1.8.0 20130625 for msm on minor 0
[ 3.293915] 8<--- cut here ---
[ 3.297012] Unable to handle kernel NULL pointer dereference at virtual address 00000028
[ 3.305244] pgd = (ptrval)
[ 3.307989] [00000028] *pgd=00000000
[ 3.311624] Internal error: Oops: 805 [#1] SMP ARM
[ 3.316430] Modules linked in:
[ 3.319503] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0+g682d702b426b #1
[ 3.326652] Hardware name: Freescale i.MX53 (Device Tree Support)
[ 3.332754] PC is at __mutex_init+0x14/0x54
[ 3.336969] LR is at msm_disp_snapshot_init+0x24/0xa0

i.MX53 does not use the DPU controller.

Fix the problem by only calling msm_disp_snapshot_init() on platforms that
use the DPU controller.

Cc: stable@vger.kernel.org
Fixes: 98659487 ("drm/msm: add support to take dpu snapshot")
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://lore.kernel.org/r/20210914174831.2044420-1-festevam@gmail.comSigned-off-by: Rob Clark <robdclark@chromium.org>

These error paths returned 1 on failure, instead of a negative error
code.  This would lead to an Oops in the caller.  A second problem is
that the check for "if (ret != -ENODATA)" did not work because "ret" was
set to 1.

Fixes: 5785dd7a ("drm/msm: Fix duplicate gpu node in icc summary")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20211001125904.GK2283@kiliSigned-off-by: Rob Clark <robdclark@chromium.org>

This code returns 1 on error instead of a negative error.  It leads to
an Oops in the caller.  A second problem is that the check for
"if (ret != -ENODATA)" cannot be true because "ret" is set to 1.

Fixes: 5785dd7a ("drm/msm: Fix duplicate gpu node in icc summary")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20211001125759.GJ2283@kiliSigned-off-by: Rob Clark <robdclark@chromium.org>

The initialization of pointer dev dereferences pointer edp before
edp is null checked, so there is a potential null pointer deference
issue. Fix this by only dereferencing edp after edp has been null
checked.

Addresses-Coverity: ("Dereference before null check")
Fixes: ab5b0107 ("drm/msm: Initial add eDP support in msm drm driver (v5)")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20210929121857.213922-1-colin.king@canonical.comSigned-off-by: Rob Clark <robdclark@chromium.org>

Since f35a2a99 ("drm/encoder: make encoder control functions
optional") drm_mode_config_validate would print warnings if both cursor
plane and cursor functions are provided. Restore separate set of
drm_crtc_funcs to be used if separate cursor plane is provided.

[    6.556046] ------------[ cut here ]------------
[    6.556071] [CRTC:93:crtc-0] must not have both a cursor plane and a cursor_set func
[    6.556091] WARNING: CPU: 1 PID: 76 at drivers/gpu/drm/drm_mode_config.c:648 drm_mode_config_validate+0x238/0x4d0
[    6.567453] Modules linked in:
[    6.577604] CPU: 1 PID: 76 Comm: kworker/u8:2 Not tainted 5.15.0-rc1-dirty #43
[    6.580557] Hardware name: Qualcomm Technologies, Inc. DB820c (DT)
[    6.587763] Workqueue: events_unbound deferred_probe_work_func
[    6.593926] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    6.599740] pc : drm_mode_config_validate+0x238/0x4d0
[    6.606596] lr : drm_mode_config_validate+0x238/0x4d0
[    6.611804] sp : ffff8000121b3980
[    6.616838] x29: ffff8000121b3990 x28: 0000000000000000 x27: 0000000000000001
[    6.620140] x26: ffff8000114cde50 x25: ffff8000114cdd40 x24: ffff0000987282d8
[    6.627258] x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000001
[    6.634376] x20: ffff000098728000 x19: ffff000080a39000 x18: ffffffffffffffff
[    6.641494] x17: 3136564e3631564e x16: 0000000000000324 x15: ffff800011c78709
[    6.648613] x14: 0000000000000000 x13: ffff800011a22850 x12: 00000000000009ab
[    6.655730] x11: 0000000000000339 x10: ffff800011a22850 x9 : ffff800011a22850
[    6.662848] x8 : 00000000ffffefff x7 : ffff800011a7a850 x6 : ffff800011a7a850
[    6.669966] x5 : 000000000000bff4 x4 : 40000000fffff339 x3 : 0000000000000000
[    6.677084] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00008093b800
[    6.684205] Call trace:
[    6.691319]  drm_mode_config_validate+0x238/0x4d0
[    6.693577]  drm_dev_register+0x17c/0x210
[    6.698435]  msm_drm_bind+0x4b4/0x694
[    6.702429]  try_to_bring_up_master+0x164/0x1d0
[    6.706075]  __component_add+0xa0/0x170
[    6.710415]  component_add+0x14/0x20
[    6.714234]  msm_hdmi_dev_probe+0x1c/0x2c
[    6.718053]  platform_probe+0x68/0xe0
[    6.721959]  really_probe.part.0+0x9c/0x30c
[    6.725606]  __driver_probe_device+0x98/0x144
[    6.729600]  driver_probe_device+0xc8/0x15c
[    6.734114]  __device_attach_driver+0xb4/0x120
[    6.738106]  bus_for_each_drv+0x78/0xd0
[    6.742619]  __device_attach+0xdc/0x184
[    6.746351]  device_initial_probe+0x14/0x20
[    6.750172]  bus_probe_device+0x9c/0xa4
[    6.754337]  deferred_probe_work_func+0x88/0xc0
[    6.758158]  process_one_work+0x1d0/0x370
[    6.762671]  worker_thread+0x2c8/0x470
[    6.766839]  kthread+0x15c/0x170
[    6.770483]  ret_from_fork+0x10/0x20
[    6.773870] ---[ end trace 5884eb76cd26d274 ]---
[    6.777500] ------------[ cut here ]------------
[    6.782043] [CRTC:93:crtc-0] must not have both a cursor plane and a cursor_move func
[    6.782063] WARNING: CPU: 1 PID: 76 at drivers/gpu/drm/drm_mode_config.c:654 drm_mode_config_validate+0x290/0x4d0
[    6.794362] Modules linked in:
[    6.804600] CPU: 1 PID: 76 Comm: kworker/u8:2 Tainted: G        W         5.15.0-rc1-dirty #43
[    6.807555] Hardware name: Qualcomm Technologies, Inc. DB820c (DT)
[    6.816148] Workqueue: events_unbound deferred_probe_work_func
[    6.822311] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    6.828126] pc : drm_mode_config_validate+0x290/0x4d0
[    6.834981] lr : drm_mode_config_validate+0x290/0x4d0
[    6.840189] sp : ffff8000121b3980
[    6.845223] x29: ffff8000121b3990 x28: 0000000000000000 x27: 0000000000000001
[    6.848525] x26: ffff8000114cde50 x25: ffff8000114cdd40 x24: ffff0000987282d8
[    6.855643] x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000001
[    6.862763] x20: ffff000098728000 x19: ffff000080a39000 x18: ffffffffffffffff
[    6.869879] x17: 3136564e3631564e x16: 0000000000000324 x15: ffff800011c790c2
[    6.876998] x14: 0000000000000000 x13: ffff800011a22850 x12: 0000000000000a2f
[    6.884116] x11: 0000000000000365 x10: ffff800011a22850 x9 : ffff800011a22850
[    6.891234] x8 : 00000000ffffefff x7 : ffff800011a7a850 x6 : ffff800011a7a850
[    6.898351] x5 : 000000000000bff4 x4 : 40000000fffff365 x3 : 0000000000000000
[    6.905470] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00008093b800
[    6.912590] Call trace:
[    6.919702]  drm_mode_config_validate+0x290/0x4d0
[    6.921960]  drm_dev_register+0x17c/0x210
[    6.926821]  msm_drm_bind+0x4b4/0x694
[    6.930813]  try_to_bring_up_master+0x164/0x1d0
[    6.934459]  __component_add+0xa0/0x170
[    6.938799]  component_add+0x14/0x20
[    6.942619]  msm_hdmi_dev_probe+0x1c/0x2c
[    6.946438]  platform_probe+0x68/0xe0
[    6.950345]  really_probe.part.0+0x9c/0x30c
[    6.953991]  __driver_probe_device+0x98/0x144
[    6.957984]  driver_probe_device+0xc8/0x15c
[    6.962498]  __device_attach_driver+0xb4/0x120
[    6.966492]  bus_for_each_drv+0x78/0xd0
[    6.971004]  __device_attach+0xdc/0x184
[    6.974737]  device_initial_probe+0x14/0x20
[    6.978556]  bus_probe_device+0x9c/0xa4
[    6.982722]  deferred_probe_work_func+0x88/0xc0
[    6.986543]  process_one_work+0x1d0/0x370
[    6.991057]  worker_thread+0x2c8/0x470
[    6.995223]  kthread+0x15c/0x170
[    6.998869]  ret_from_fork+0x10/0x20
[    7.002255] ---[ end trace 5884eb76cd26d275 ]---

Fixes: aa649e87 ("drm/msm/mdp5: mdp5_crtc: Restore cursor state only if LM cursors are enabled")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20210925192824.3416259-1-dmitry.baryshkov@linaro.orgSigned-off-by: Rob Clark <robdclark@chromium.org>

The return type of ktime_divns() is s64. The timeout_to_jiffies() currently
assigns the result of this ktime_divns() to unsigned long, which on 32 bit
systems may overflow. Furthermore, the result of this function is sometimes
also passed to functions which expect signed long, dma_fence_wait_timeout()
is one such example.

Fix this by adjusting the type of remaining_jiffies to s64, so we do not
suffer overflow there, and return a value limited to range of 0..INT_MAX,
which is safe for all usecases of this timeout.

The above overflow can be triggered if userspace passes in too large timeout
value, larger than INT_MAX / HZ seconds. The kernel detects it and complains
about "schedule_timeout: wrong timeout value %lx" and generates a warning
backtrace.

Note that this fixes commit 6cedb8b3 ("drm/msm: avoid using 'timespec'"),
because the previously used timespec_to_jiffies() function returned unsigned
long instead of s64:
static inline unsigned long timespec_to_jiffies(const struct timespec *value)

Fixes: 6cedb8b3 ("drm/msm: avoid using 'timespec'")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Jordan Crouse <jcrouse@codeaurora.org>
Cc: Rob Clark <robdclark@chromium.org>
Cc: stable@vger.kernel.org # 5.6+
Acked-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20210917005913.157379-1-marex@denx.deSigned-off-by: Rob Clark <robdclark@chromium.org>

There is no devfreq on a3xx at the moment since gpu_busy is not
implemented. This means that msm_devfreq_init() will return early
and the entire devfreq setup is skipped.

However, msm_devfreq_active() and msm_devfreq_idle() are still called
unconditionally later, causing a NULL pointer dereference:

  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
  Internal error: Oops: 96000004 [#1] PREEMPT SMP
  CPU: 0 PID: 133 Comm: ring0 Not tainted 5.15.0-rc1 #4
  Hardware name: Longcheer L8150 (DT)
  pc : mutex_lock_io+0x2bc/0x2f0
  lr : msm_devfreq_active+0x3c/0xe0 [msm]
  Call trace:
   mutex_lock_io+0x2bc/0x2f0
   msm_gpu_submit+0x164/0x180 [msm]
   msm_job_run+0x54/0xe0 [msm]
   drm_sched_main+0x2b0/0x4a0 [gpu_sched]
   kthread+0x154/0x160
   ret_from_fork+0x10/0x20

Fix this by adding a check in msm_devfreq_active/idle() which ensures
that devfreq was actually initialized earlier.

Fixes: 9bc95570 ("drm/msm: Devfreq tuning")
Reported-by: Nikita Travkin <nikita@trvn.ru>
Tested-by: Nikita Travkin <nikita@trvn.ru>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20210913164556.16284-1-stephan@gerhold.netSigned-off-by: Rob Clark <robdclark@chromium.org>

Currently there is audio not working problem after system resume from suspend
if hdmi monitor stay plugged in at DUT. However this problem does not happen
at normal operation but at a particular test case. The root cause is DP driver
signal audio with connected state at resume which trigger audio trying to setup
audio data path through DP main link but failed due to display port is not setup
and enabled by upper layer framework yet. This patch only have DP driver signal
audio only when DP is in disconnected state so that audio option shows correct
state after system resume. DP driver will not signal audio with connected state
until display enabled executed by upper layer framework where display port is
setup completed and main link is running.

Changes in V2:
-- add details commit text

Fixes: afc9b8b6 ("drm/msm/dp: signal audio plugged change at dp_pm_resume")
Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/1632932224-25102-1-git-send-email-khsieh@codeaurora.orgSigned-off-by: Rob Clark <robdclark@chromium.org>

This reverts commit c1ec54b7.

Commit c1ec54b7
("drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb")
would cause numerous mtk cmdq mailbox driver warning:

WARNING: CPU: 0 PID: 0 at drivers/mailbox/mtk-cmdq-mailbox.c:198
cmdq_task_exec_done+0xb8/0xe0

So revert that patch.
Reported-by: Enric Balletbo Serra <eballetbo@gmail.com>
Tested-by: Enric Balletbo Serra <eballetbo@gmail.com>
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>

This reverts commit f4be17cd.

Commit c1ec54b7
("drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb")
would cause numerous mtk cmdq mailbox driver warning:

WARNING: CPU: 0 PID: 0 at drivers/mailbox/mtk-cmdq-mailbox.c:198
cmdq_task_exec_done+0xb8/0xe0

So revert that patch and all the patches depend on that patch.
Reported-by: Enric Balletbo Serra <eballetbo@gmail.com>
Tested-by: Enric Balletbo Serra <eballetbo@gmail.com>
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>

This reverts commit 8cdcb365.

Commit c1ec54b7
("drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb")
would cause numerous mtk cmdq mailbox driver warning:

WARNING: CPU: 0 PID: 0 at drivers/mailbox/mtk-cmdq-mailbox.c:198
cmdq_task_exec_done+0xb8/0xe0

So revert that patch and all the patches depend on that patch.
Reported-by: Enric Balletbo Serra <eballetbo@gmail.com>
Tested-by: Enric Balletbo Serra <eballetbo@gmail.com>
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>

This reverts commit bc9241be.

Commit c1ec54b7
("drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb")
would cause numerous mtk cmdq mailbox driver warning:

WARNING: CPU: 0 PID: 0 at drivers/mailbox/mtk-cmdq-mailbox.c:198
cmdq_task_exec_done+0xb8/0xe0

So revert that patch and all the patches depend on that patch.
Reported-by: Enric Balletbo Serra <eballetbo@gmail.com>
Tested-by: Enric Balletbo Serra <eballetbo@gmail.com>
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>

This reverts commit 9efb16c2.

Commit c1ec54b7
("drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb")
would cause numerous mtk cmdq mailbox driver warning:

WARNING: CPU: 0 PID: 0 at drivers/mailbox/mtk-cmdq-mailbox.c:198
cmdq_task_exec_done+0xb8/0xe0

So revert that patch and all the patches depend on that patch.
Reported-by: Enric Balletbo Serra <eballetbo@gmail.com>
Tested-by: Enric Balletbo Serra <eballetbo@gmail.com>
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>

Seems to fix some object-debug splat which appeared while debugging
something unrelated.

v2: s/guc_blocked/guc_state.blocked/
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Fixes: 62eaf0ae ("drm/i915/guc: Support request cancellation")
Link: https://patchwork.freedesktop.org/patch/msgid/20210924144646.4096402-1-matthew.auld@intel.com
(cherry picked from commit d576b31b)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Pull powerpc fixes from Michael Ellerman:
 "A bit of a big batch, partly because I didn't send any last week, and
  also just because the BPF fixes happened to land this week.

  Summary:

   - Fix a regression hit by the IPR SCSI driver, introduced by the
     recent addition of MSI domains on pseries.

   - A big series including 8 BPF fixes, some with potential security
     impact and the rest various code generation issues.

   - Fix our program check assembler entry path, which was accidentally
     jumping into a gas macro and generating strange stack frames, which
     could confuse find_bug().

   - A couple of fixes, and related changes, to fix corner cases in our
     machine check handling.

   - Fix our DMA IOMMU ops, which were not always returning the optimal
     DMA mask, leading to at least one device falling back to 32-bit DMA
     when it shouldn't.

   - A fix for KUAP handling on 32-bit Book3S.

   - Fix crashes seen when kdumping on some pseries systems.

  Thanks to Naveen N. Rao, Nicholas Piggin, Alexey Kardashevskiy, Cédric
  Le Goater, Christophe Leroy, Mahesh Salgaonkar, Abdul Haleem,
  Christoph Hellwig, Johan Almbladh, Stan Johnson"

* tag 'powerpc-5.15-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  pseries/eeh: Fix the kdump kernel crash during eeh_pseries_init
  powerpc/32s: Fix kuap_kernel_restore()
  powerpc/pseries/msi: Add an empty irq_write_msi_msg() handler
  powerpc/64s: Fix unrecoverable MCE calling async handler from NMI
  powerpc/64/interrupt: Reconcile soft-mask state in NMI and fix false BUG
  powerpc/64: warn if local irqs are enabled in NMI or hardirq context
  powerpc/traps: do not enable irqs in _exception
  powerpc/64s: fix program check interrupt emergency stack path
  powerpc/bpf ppc32: Fix BPF_SUB when imm == 0x80000000
  powerpc/bpf ppc32: Do not emit zero extend instruction for 64-bit BPF_END
  powerpc/bpf ppc32: Fix JMP32_JSET_K
  powerpc/bpf ppc32: Fix ALU32 BPF_ARSH operation
  powerpc/bpf: Emit stf barrier instruction sequences for BPF_NOSPEC
  powerpc/security: Add a helper to query stf_barrier type
  powerpc/bpf: Fix BPF_SUB when imm == 0x80000000
  powerpc/bpf: Fix BPF_MOD when imm == 1
  powerpc/bpf: Validate branch ranges
  powerpc/lib: Add helper to check if offset is within conditional branch range
  powerpc/iommu: Report the correct most efficient DMA mask for PCI devices

Pull objtool fixes from Borislav Petkov:

 - Remove an extra section.len member in favour of section.sh_size

 - Align .altinstructions section creation with the kernel's by creating
   them with entry size of 0

 - Fix objtool to convert a reloc symbol to a section offset and not to
   not warn about not knowing how

* tag 'objtool_urgent_for_v5.15_rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  objtool: Remove redundant 'len' field from struct section
  objtool: Make .altinstructions section entry size consistent
  objtool: Remove reloc symbol type checks in get_alt_entry()

Pull x86 fixes from Borislav Petkov:

 - A FPU fix to properly handle invalid MXCSR values: 32-bit masks them
   out due to historical reasons and 64-bit kernels reject them

 - A fix to clear X86_FEATURE_SMAP when support for is not
   config-enabled

 - Three fixes correcting misspelled Kconfig symbols used in code

 - Two resctrl object cleanup fixes

 - Yet another attempt at fixing the neverending saga of botched x86
   timers, this time because some incredibly smart hardware decides to
   turn off the HPET timer in a low power state - who cares if the OS is
   relying on it...

 - Check the full return value range of an SEV VMGEXIT call to determine
   whether it returned an error

* tag 'x86_urgent_for_v5.15_rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/fpu: Restore the masking out of reserved MXCSR bits
  x86/Kconfig: Correct reference to MWINCHIP3D
  x86/platform/olpc: Correct ifdef symbol to intended CONFIG_OLPC_XO15_SCI
  x86/entry: Clear X86_FEATURE_SMAP when CONFIG_X86_SMAP=n
  x86/entry: Correct reference to intended CONFIG_64_BIT
  x86/resctrl: Fix kfree() of the wrong type in domain_add_cpu()
  x86/resctrl: Free the ctrlval arrays when domain_setup_mon_state() fails
  x86/hpet: Use another crystalball to evaluate HPET usability
  x86/sev: Return an error on a returned non-zero SW_EXITINFO1[31:0]

Pull i2c fixes from Wolfram Sang:
 "Three driver bugfixes and one leak fix for the core"

* 'i2c/for-current-fixed' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
  i2c: mlxcpld: Modify register setting for 400KHz frequency
  i2c: mlxcpld: Fix criteria for frequency setting
  i2c: mediatek: Add OFFSET_EXT_CONF setting back
  i2c: acpi: fix resource leak in reconfiguration device addition

Pull SCSI fixes from James Bottomley:
 "Five fixes, all in drivers.

  The big change is the UFS task management rework, with lpfc next and
  the rest being fairly minor and obvious fixes"

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  scsi: iscsi: Fix iscsi_task use after free
  scsi: lpfc: Fix memory overwrite during FC-GS I/O abort handling
  scsi: elx: efct: Delete stray unlock statement
  scsi: ufs: core: Fix task management completion
  scsi: acornscsi: Remove scsi_cmd_to_tag() reference

Pull block fixes from Jens Axboe:
 "Two small fixes for this release:

   - Add missing QUEUE_FLAG_HCTX_ACTIVE in the debugfs handling
     (Johannes)

   - Fix double free / UAF issue in __alloc_disk_node (Tetsuo)"

* tag 'block-5.15-2021-10-09' of git://git.kernel.dk/linux-block:
  block: decode QUEUE_FLAG_HCTX_ACTIVE in debugfs output
  block: genhd: fix double kfree() in __alloc_disk_node()

Pull ksmbd fixes from Steve French:
 "Six fixes for the ksmbd kernel server, including two additional
  overflow checks, a fix for oops, and some cleanup (e.g. remove dead
  code for less secure dialects that has been removed)"

* tag '5.15-rc4-ksmbd-fixes' of git://git.samba.org/ksmbd:
  ksmbd: fix oops from fuse driver
  ksmbd: fix version mismatch with out of tree
  ksmbd: use buf_data_size instead of recalculation in smb3_decrypt_req()
  ksmbd: remove the leftover of smb2.0 dialect support
  ksmbd: check strictly data area in ksmbd_smb2_check_message()
  ksmbd: add the check to vaildate if stream protocol length exceeds maximum value

Pull RISC-V fixes from Palmer Dabbelt:

 - A pair of fixes (along with the necessory cleanup) to our VDSO, to
   avoid a locking during OOM and to prevent the text from overflowing
   into the data page

 - A fix to checksyscalls to teach it about our rv32 UABI

 - A fix to add clone3() to the rv32 UABI, which was pointed out by
   checksyscalls

 - A fix to properly flush the icache on the local CPU in addition to
   the remote CPUs

* tag 'riscv-for-linus-5.15-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
  checksyscalls: Unconditionally ignore fstat{,at}64
  riscv: Flush current cpu icache before other cpus
  RISC-V: Include clone3() on rv32
  riscv/vdso: make arch_setup_additional_pages wait for mmap_sem for write killable
  riscv/vdso: Move vdso data page up front
  riscv/vdso: Refactor asm/vdso.h

Pull s390 fixes from Vasily Gorbik:

 - Fix potential memory leak on a error path in eBPF

 - Fix handling of zpci device on reserve

* tag 's390-5.15-5' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390/pci: fix zpci_zdev_put() on reserve
  bpf, s390: Fix potential memory leak about jit_data

Pull xtensa fixes from Max Filippov:

 - fix build/boot issues caused by CONFIG_OF vs CONFIC_USE_OF usage

 - fix reset handler for xtfpga boards

* tag 'xtensa-20211008' of git://github.com/jcmvbkbc/linux-xtensa:
  xtensa: xtfpga: Try software restart before simulating CPU reset
  xtensa: xtfpga: use CONFIG_USE_OF instead of CONFIG_OF
  xtensa: call irqchip_init only when CONFIG_USE_OF is selected
  xtensa: use CONFIG_USE_OF instead of CONFIG_OF