linux-stable.git/drivers/gpu/drm/bridge, branch v6.7.2

drm/bridge: tc358767: Fix return value on error case

2024-01-25T23:45:02+00:00

[ Upstream commit 32bd29b619638256c5b75fb021d6d9f12fc4a984 ]

If the hpd_pin is invalid, the driver returns 'ret'. But 'ret' contains
0, instead of an error value.

Return -EINVAL instead.

Fixes: f25ee5017e4f ("drm/bridge: tc358767: add IRQ and HPD support")
Acked-by: Maxime Ripard 
Signed-off-by: Tomi Valkeinen 
Link: https://patchwork.freedesktop.org/patch/msgid/20231103-uninit-fixes-v2-4-c22b2444f5f5@ideasonboard.com
Signed-off-by: Sasha Levin

drm/bridge: cdns-mhdp8546: Fix use of uninitialized variable

2024-01-25T23:45:02+00:00

[ Upstream commit 155d6fb61270dd297f128731cd155080deee8f3a ]

'ret' could be uninitialized at the end of the function, although it's
not clear if that can happen in practice.

Fixes: 6a3608eae6d3 ("drm: bridge: cdns-mhdp8546: Enable HDCP")
Acked-by: Maxime Ripard 
Signed-off-by: Tomi Valkeinen 
Link: https://patchwork.freedesktop.org/patch/msgid/20231103-uninit-fixes-v2-3-c22b2444f5f5@ideasonboard.com
Signed-off-by: Sasha Levin

Revert "drm/bridge: Add 200ms delay to wait FW HPD status stable"

2024-01-25T23:44:59+00:00

[ Upstream commit af3145aa142c92409d3b123ff87ff0b5fd0bf849 ]

This reverts commit 330140d7319fcc4ec68bd924ea212e476bf12275

200ms delay will cause panel display image later than backlight
turn on, revert this patch.

Fixes: 330140d7319fcc ("drm/bridge: Add 200ms delay to wait FW HPD status stable")
Signed-off-by: Xin Ji 
Reviewed-by: Robert Foss 
Signed-off-by: Robert Foss 
Link: https://patchwork.freedesktop.org/patch/msgid/20231120091038.284825-1-xji@analogixsemi.com
Signed-off-by: Sasha Levin

drm/bridge: imx93-mipi-dsi: Fix a couple of building warnings

2024-01-25T23:44:59+00:00

[ Upstream commit 325b71e820b67569048c621227266783442b75ed ]

Fix a couple of building warnings on used uninitialized 'best_m' and
'best_n' local variables by initializing 'best_m' to zero and 'best_n'
to UINT_MAX.  This makes compiler happy only.  No functional change.

Fixes: ce62f8ea7e3f ("drm/bridge: imx: Add i.MX93 MIPI DSI support")
Reported-by: kernel test robot 
Closes: https://lore.kernel.org/oe-kbuild-all/202311151746.f7u7dzbZ-lkp@intel.com/
Signed-off-by: Liu Ying 
Reviewed-by: Robert Foss 
Signed-off-by: Robert Foss 
Link: https://patchwork.freedesktop.org/patch/msgid/20231123051807.3818342-1-victor.liu@nxp.com
Signed-off-by: Sasha Levin

drm/bridge: tpd12s015: Drop buggy __exit annotation for remove function

2024-01-25T23:44:58+00:00

[ Upstream commit ce3e112e7ae854249d8755906acc5f27e1542114 ]

With tpd12s015_remove() marked with __exit this function is discarded
when the driver is compiled as a built-in. The result is that when the
driver unbinds there is no cleanup done which results in resource
leakage or worse.

Fixes: cff5e6f7e83f ("drm/bridge: Add driver for the TI TPD12S015 HDMI level shifter")
Signed-off-by: Uwe Kleine-König 
Signed-off-by: Thomas Zimmermann 
Link: https://patchwork.freedesktop.org/patch/msgid/20231102165640.3307820-19-u.kleine-koenig@pengutronix.de
Signed-off-by: Sasha Levin

drm/bridge: ps8640: Fix size mismatch warning w/ len

2023-12-19T15:11:16+00:00

After commit 26195af57798 ("drm/bridge: ps8640: Drop the ability of
ps8640 to fetch the EDID"), I got an error compiling:

  error: comparison of distinct pointer types
  ('typeof (len) *' (aka 'unsigned int *') and
   'typeof (msg->size) *' (aka 'unsigned long *'))
  [-Werror,-Wcompare-distinct-pointer-types]

Fix it by declaring the `len` as size_t.

The above error only shows up on downstream kernels without commit
d03eba99f5bf ("minmax: allow min()/max()/clamp() if the arguments have
the same signedness."), but since commit 26195af57798 ("drm/bridge:
ps8640: Drop the ability of ps8640 to fetch the EDID") is a "Fix" that
will likely be backported it seems nice to make it easy. ...plus it's
more correct to declare `len` as size_t anyway.

Fixes: 26195af57798 ("drm/bridge: ps8640: Drop the ability of ps8640 to fetch the EDID")
Reviewed-by: Stephen Boyd 
Signed-off-by: Douglas Anderson 
Link: https://patchwork.freedesktop.org/patch/msgid/20231218090454.1.I5c6eb80b2f746439c4b58efab788e00701d08759@changeid

drm/bridge: ti-sn65dsi86: Never store more than msg->size bytes in AUX xfer

2023-12-18T16:44:15+00:00

For aux reads, the value `msg->size` indicates the size of the buffer
provided by `msg->buffer`. We should never in any circumstances write
more bytes to the buffer since it may overflow the buffer.

In the ti-sn65dsi86 driver there is one code path that reads the
transfer length from hardware. Even though it's never been seen to be
a problem, we should make extra sure that the hardware isn't
increasing the length since doing so would cause us to overrun the
buffer.

Fixes: 982f589bde7a ("drm/bridge: ti-sn65dsi86: Update reply on aux failures")
Reviewed-by: Stephen Boyd 
Reviewed-by: Guenter Roeck 
Signed-off-by: Douglas Anderson 
Link: https://patchwork.freedesktop.org/patch/msgid/20231214123752.v3.2.I7b83c0f31aeedc6b1dc98c7c741d3e1f94f040f8@changeid

drm/bridge: parade-ps8640: Never store more than msg->size bytes in AUX xfer

2023-12-18T16:44:01+00:00

While testing, I happened to notice a random crash that looked like:

  Kernel panic - not syncing: stack-protector:
  Kernel stack is corrupted in: drm_dp_dpcd_probe+0x120/0x120

Analysis of drm_dp_dpcd_probe() shows that we pass in a 1-byte buffer
(allocated on the stack) to the aux->transfer() function. Presumably
if the aux->transfer() writes more than one byte to this buffer then
we're in a bad shape.

Dropping into kgdb, I noticed that "aux->transfer" pointed at
ps8640_aux_transfer().

Reading through ps8640_aux_transfer(), I can see that there are cases
where it could write more bytes to msg->buffer than were specified by
msg->size. This could happen if the hardware reported back something
bogus to us. Let's fix this so we never write more than msg->size
bytes. We'll still read all the bytes from the hardware just in case
the hardware requires it since the aux transfer data comes through an
auto-incrementing register.

NOTE: I have no actual way to reproduce this issue but it seems likely
this is what was happening in the crash I looked at.

Fixes: 13afcdd7277e ("drm/bridge: parade-ps8640: Add support for AUX channel")
Reviewed-by: Stephen Boyd 
Reviewed-by: Guenter Roeck 
Signed-off-by: Douglas Anderson 
Link: https://patchwork.freedesktop.org/patch/msgid/20231214123752.v3.1.I9d1afcaad76a3e2c0ca046dc4adbc2b632c22eda@changeid

drm/bridge: tc358768: select CONFIG_VIDEOMODE_HELPERS

2023-12-05T08:32:15+00:00

A dependency on this feature was recently introduced:

x86_64-linux-ld: vmlinux.o: in function `tc358768_bridge_pre_enable':
tc358768.c:(.text+0xbe3dae): undefined reference to `drm_display_mode_to_videomode'

Make sure this is always enabled.

Fixes: e5fb21678136 ("drm/bridge: tc358768: Use struct videomode")
Signed-off-by: Arnd Bergmann 
Reviewed-by: Neil Armstrong 
Link: https://lore.kernel.org/r/20231204072814.968816-1-arnd@kernel.org
Signed-off-by: Neil Armstrong 
Link: https://patchwork.freedesktop.org/patch/msgid/20231204072814.968816-1-arnd@kernel.org

Revert "drm/bridge: panel: Add a device link between drm device and panel device"

2023-11-28T10:07:30+00:00

This reverts commit 199cf07ebd2b0d41185ac79b895547d45610b681.

This patch creates bugs on devices where the DRM device is
the ancestor of the panel devices.

Attempts to fix this have failed because it leads to using
device core functionality which is questionable.

Reported-by: Linus Walleij 
Link: https://lore.kernel.org/lkml/CACRpkdaGzXD6HbiX7mVUNJAJtMEPG00Pp6+nJ1P0JrfJ-ArMvQ@mail.gmail.com/T/
Signed-off-by: Linus Walleij 
Acked-by: Neil Armstrong 
Link: https://lore.kernel.org/r/20231128-revert-panel-fix-v1-3-69bb05048dae@linaro.org
Signed-off-by: Neil Armstrong 
Link: https://patchwork.freedesktop.org/patch/msgid/20231128-revert-panel-fix-v1-3-69bb05048dae@linaro.org