Hello Tomi, Alexander,
On 24/01/25 13:38, Alexander Stein wrote:
Hi,
Am Donnerstag, 23. Januar 2025, 17:20:34 CET schrieb Tomi Valkeinen:
Hi,
On 16/01/2025 13:16, Jayesh Choudhary wrote:
For the cases we have DRM_BRIDGE_ATTACH_NO_CONNECTOR flag set,
Any idea if any other platform than K3 i
Hi,
Am Donnerstag, 23. Januar 2025, 17:20:34 CET schrieb Tomi Valkeinen:
> Hi,
>
> On 16/01/2025 13:16, Jayesh Choudhary wrote:
> > For the cases we have DRM_BRIDGE_ATTACH_NO_CONNECTOR flag set,
>
> Any idea if any other platform than K3 is using this driver? tidss
> supports DRM_BRIDGE_ATTACH_
Hi,
On 16/01/2025 13:16, Jayesh Choudhary wrote:
For the cases we have DRM_BRIDGE_ATTACH_NO_CONNECTOR flag set,
Any idea if any other platform than K3 is using this driver? tidss
supports DRM_BRIDGE_ATTACH_NO_CONNECTOR, so if K3 is the only user, we
could drop the legacy !DRM_BRIDGE_ATTACH_N
For the cases we have DRM_BRIDGE_ATTACH_NO_CONNECTOR flag set,
the connector structure is not initialised in the bridge. That's done
by encoder. So in case of some failure in cdns_mhdp_atomic_enable,
when we schedule work for modeset_retry_work, we will use the mutex
of connector which will result
On Mon, 8 Apr 2024 15:58:10 +0300, Aleksandr Mishin wrote:
> In cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() is
> assigned to mhdp_state->current_mode, and there is a dereference of it in
> drm_mode_set_name(), which will lead to a NULL pointer dereference on
> failure of drm
In cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() is
assigned to mhdp_state->current_mode, and there is a dereference of it in
drm_mode_set_name(), which will lead to a NULL pointer dereference on
failure of drm_mode_duplicate().
Fix this bug add a check of mhdp_state->current
