kernel/linux.git/drivers/gpu/drm/bridge, branch v6.6.12

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

2024-01-10T16:16:47+00:00

[ Upstream commit 35ba6bd582cf926a082296b7e9a876ec81136cb1 ] 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 Signed-off-by: Sasha Levin

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

2024-01-10T16:16:47+00:00

[ Upstream commit aca58eac52b88138ab98c814afb389a381725cd7 ] 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 Signed-off-by: Sasha Levin

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

2024-01-10T16:16:47+00:00

[ Upstream commit 3164c8a70073d43629b4e11e083d3d2798f7750f ] 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 Signed-off-by: Sasha Levin

drm/bridge: tc358768: select CONFIG_VIDEOMODE_HELPERS

2023-12-13T17:45:16+00:00

[ Upstream commit 26513300978f7285c3e776c144f27ef71be61f57 ] 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 Signed-off-by: Sasha Levin

drm: bridge: it66121: ->get_edid callback must not return err pointers

2023-11-28T17:20:16+00:00

commit 81995ee1620318b4c7bbeb02bcc372da2c078c76 upstream. The drm stack does not expect error valued pointers for EDID anywhere. Fixes: e66856508746 ("drm: bridge: it66121: Set DDC preamble only once before reading EDID") Cc: Paul Cercueil Cc: Robert Foss Cc: Phong LE Cc: Neil Armstrong Cc: Andrzej Hajda Cc: Robert Foss Cc: Laurent Pinchart Cc: Jonas Karlman Cc: Jernej Skrabec Cc: # v6.3+ Signed-off-by: Jani Nikula Reviewed-by: Neil Armstrong Signed-off-by: Paul Cercueil Link: https://patchwork.freedesktop.org/patch/msgid/20230914131159.2472513-1-jani.nikula@intel.com Signed-off-by: Greg Kroah-Hartman

drm/bridge: lt9611uxc: fix the race in the error path

2023-11-20T10:59:12+00:00

[ Upstream commit 15fe53be46eaf4f6339cd433972ecc90513e3076 ] If DSI host attachment fails, the LT9611UXC driver will remove the bridge without ensuring that there is no outstanding HPD work being done. In rare cases this can result in the warnings regarding the mutex being incorrect. Fix this by forcebly freing IRQ and flushing the work. DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 0 PID: 10 at kernel/locking/mutex.c:582 __mutex_lock+0x468/0x77c Modules linked in: CPU: 0 PID: 10 Comm: kworker/0:1 Tainted: G U 6.6.0-rc5-next-20231011-gd81f81c2b682-dirty #1206 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Workqueue: events lt9611uxc_hpd_work pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __mutex_lock+0x468/0x77c lr : __mutex_lock+0x468/0x77c sp : ffff8000800a3c70 x29: ffff8000800a3c70 x28: 0000000000000000 x27: ffffd595fe333000 x26: ffff7c2f0002c005 x25: ffffd595ff1b3000 x24: ffffd595fccda5a0 x23: 0000000000000000 x22: 0000000000000002 x21: ffff7c2f056d91c8 x20: 0000000000000000 x19: ffff7c2f056d91c8 x18: fffffffffffe8db0 x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000000 x14: 000000000006efb8 x13: 0000000000000000 x12: 0000000000000037 x11: 0000000000000001 x10: 0000000000001470 x9 : ffff8000800a3ae0 x8 : ffff7c2f0027f8d0 x7 : ffff7c2f0027e400 x6 : ffffd595fc702b54 x5 : 0000000000000000 x4 : ffff8000800a0000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff7c2f0027e400 Call trace: __mutex_lock+0x468/0x77c mutex_lock_nested+0x24/0x30 drm_bridge_hpd_notify+0x2c/0x5c lt9611uxc_hpd_work+0x6c/0x80 process_one_work+0x1ec/0x51c worker_thread+0x1ec/0x3e4 kthread+0x120/0x124 ret_from_fork+0x10/0x20 irq event stamp: 15799 hardirqs last enabled at (15799): [] finish_task_switch.isra.0+0xa8/0x278 hardirqs last disabled at (15798): [] __schedule+0x7b8/0xbd8 softirqs last enabled at (15794): [] __do_softirq+0x498/0x4e0 softirqs last disabled at (15771): [] ____do_softirq+0x10/0x1c Fixes: bc6fa8676ebb ("drm/bridge/lontium-lt9611uxc: move HPD notification out of IRQ handler") Signed-off-by: Dmitry Baryshkov Reviewed-by: Robert Foss Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20231011220002.382422-1-dmitry.baryshkov@linaro.org Signed-off-by: Sasha Levin

drm/bridge: tc358768: Fix tc358768_ns_to_cnt()

2023-11-20T10:59:10+00:00

[ Upstream commit f1dabbe645065d20ca863c8d446c74c59ca1ca9d ] The tc358768_ns_to_cnt() is, most likely, supposed to do a div-round-up operation, but it misses subtracting one from the dividend. Fix this by just using DIV_ROUND_UP(). Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver") Reviewed-by: Peter Ujfalusi Tested-by: Maxim Schwalm # Asus TF700T Tested-by: Marcel Ziswiler Signed-off-by: Tomi Valkeinen Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20230906-tc358768-v4-11-31725f008a50@ideasonboard.com Signed-off-by: Sasha Levin

drm/bridge: tc358768: Clean up clock period code

2023-11-20T10:59:10+00:00

[ Upstream commit b3aa7b34924a9ed64cf96899cac4d8ea08cd829e ] The driver defines TC358768_PRECISION as 1000, and uses "nsk" to refer to clock periods. The original author does not remember where all this came from. Effectively the driver is using picoseconds as the unit for clock periods, yet referring to them by "nsk". Clean this up by just saying the periods are in picoseconds. Reviewed-by: Peter Ujfalusi Tested-by: Maxim Schwalm # Asus TF700T Tested-by: Marcel Ziswiler Signed-off-by: Tomi Valkeinen Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20230906-tc358768-v4-10-31725f008a50@ideasonboard.com Stable-dep-of: f1dabbe64506 ("drm/bridge: tc358768: Fix tc358768_ns_to_cnt()") Signed-off-by: Sasha Levin

drm/bridge: tc358768: Rename dsibclk to hsbyteclk

2023-11-20T10:59:10+00:00

[ Upstream commit 699cf62a7d4550759f4a50e614b1952f93de4783 ] The Toshiba documentation talks about HSByteClk when referring to the DSI HS byte clock, whereas the driver uses 'dsibclk' name. Also, in a few places the driver calculates the byte clock from the DSI clock, even if the byte clock is already available in a variable. To align the driver with the documentation, change the 'dsibclk' variable to 'hsbyteclk'. This also make it easier to visually separate 'dsibclk' and 'dsiclk' variables. Reviewed-by: Peter Ujfalusi Tested-by: Maxim Schwalm # Asus TF700T Tested-by: Marcel Ziswiler Signed-off-by: Tomi Valkeinen Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20230906-tc358768-v4-9-31725f008a50@ideasonboard.com Stable-dep-of: f1dabbe64506 ("drm/bridge: tc358768: Fix tc358768_ns_to_cnt()") Signed-off-by: Sasha Levin

drm/bridge: tc358768: Use dev for dbg prints, not priv->dev

2023-11-20T10:59:10+00:00

[ Upstream commit 89cfd50e13f1bead4350998a3a77422bef1ee0a5 ] Simplify the code by capturing the priv->dev value to dev variable, and use it. Reviewed-by: Peter Ujfalusi Tested-by: Maxim Schwalm # Asus TF700T Tested-by: Marcel Ziswiler Signed-off-by: Tomi Valkeinen Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20230906-tc358768-v4-8-31725f008a50@ideasonboard.com Stable-dep-of: f1dabbe64506 ("drm/bridge: tc358768: Fix tc358768_ns_to_cnt()") Signed-off-by: Sasha Levin