linux-stable.git/drivers/gpu/drm/exynos, branch v6.7

drm/exynos: fix a wrong error checking

2023-12-07T02:51:43+00:00

Fix a wrong error checking in exynos_drm_dma.c module.

In the exynos_drm_register_dma function, both arm_iommu_create_mapping()
and iommu_get_domain_for_dev() functions are expected to return NULL as
an error.

However, the error checking is performed using the statement
if(IS_ERR(mapping)), which doesn't provide a suitable error value.
So check if 'mapping' is NULL, and if it is, return -ENODEV.

This issue[1] was reported by Dan.

Changelog v1:
- fix build warning.

[1] https://lore.kernel.org/all/33e52277-1349-472b-a55b-ab5c3462bfcf@moroto.mountain/

Reported-by : Dan Carpenter 
Signed-off-by: Inki Dae

drm/exynos: fix a potential error pointer dereference

2023-12-07T02:51:42+00:00

Smatch reports the warning below:
drivers/gpu/drm/exynos/exynos_hdmi.c:1864 hdmi_bind()
error: 'crtc' dereferencing possible ERR_PTR()

The return value of exynos_drm_crtc_get_by_type maybe ERR_PTR(-ENODEV),
which can not be used directly. Fix this by checking the return value
before using it.

Signed-off-by: Xiang Yang 
Signed-off-by: Inki Dae

Merge drm/drm-next into drm-misc-next

2023-10-11T07:50:59+00:00

Updating drm-misc-next to the state of Linux v6.6-rc2.

Signed-off-by: Thomas Zimmermann

drm: exynos: dsi: Convert to platform remove callback returning void

2023-10-06T06:58:44+00:00

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() is renamed to .remove().

samsung_dsim_remove() returned 0 unconditionally. Make it return void
instead to convert the two related platform drivers to use
.remove_new().

Signed-off-by: Uwe Kleine-König 
Reviewed-by: Inki Dae 
Acked-by: Inki Dae 
Link: https://lore.kernel.org/r/20230919103939.1367659-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Neil Armstrong 
Link: https://patchwork.freedesktop.org/patch/msgid/20230919103939.1367659-1-u.kleine-koenig@pengutronix.de

drm/exynos: remove redundant of_match_ptr

2023-08-08T00:35:19+00:00

The driver depends on CONFIG_OF, so it is not necessary to use
of_match_ptr here.

Even for drivers that do not depend on CONFIG_OF, it's almost always
better to leave out the of_match_ptr(), since the only thing it can
possibly do is to save a few bytes of .text if a driver can be used both
with and without it. Hence we remove of_match_ptr.

Signed-off-by: Zhu Wang 
Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Inki Dae

drm/exynos: fix a possible null-pointer dereference due to data race in exynos_drm_crtc_atomic_disable()

2023-08-08T00:35:11+00:00

The variable crtc->state->event is often protected by the lock
crtc->dev->event_lock when is accessed. However, it is accessed as a
condition of an if statement in exynos_drm_crtc_atomic_disable() without
holding the lock:

  if (crtc->state->event && !crtc->state->active)

However, if crtc->state->event is changed to NULL by another thread right
after the conditions of the if statement is checked to be true, a
null-pointer dereference can occur in drm_crtc_send_vblank_event():

  e->pipe = pipe;

To fix this possible null-pointer dereference caused by data race, the
spin lock coverage is extended to protect the if statement as well as the
function call to drm_crtc_send_vblank_event().

Reported-by: BassCheck 
Link: https://sites.google.com/view/basscheck/home
Signed-off-by: Tuo Li 
Reviewed-by: Krzysztof Kozlowski 
Added relevant link.
Signed-off-by: Inki Dae

fbdev: Use _DMAMEM_ infix for DMA-memory helpers

2023-07-31T18:07:18+00:00

Change the infix for fbdev's DMA-memory helpers from _DMA_ to
_DMAMEM_. The helpers perform operations within DMA-able memory,
but they don't perform DMA operations. Naming should make this
clear. Adapt all users. No functional changes.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Sam Ravnborg 
Acked-by: Helge Deller 
Link: https://patchwork.freedesktop.org/patch/msgid/20230729193157.15446-4-tzimmermann@suse.de

drm/exynos: Set fbdev FBINFO_VIRTFB flag

2023-07-24T18:14:43+00:00

Mark the framebuffer with FBINFO_VIRTFB. The framebuffer range is
in DMA-able memory and should be accessed with the CPU's regular
memory ops.

v2:
	* drop FBINFO_FLAG_DEFAULT

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
Acked-by : Inki Dae 
Acked-by: Maxime Ripard 
Cc: Inki Dae 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Cc: Krzysztof Kozlowski 
Cc: Alim Akhtar 
Link: https://patchwork.freedesktop.org/patch/msgid/20230707083422.18691-8-tzimmermann@suse.de

drm/exynos: Use fbdev DMA helpers

2023-07-24T18:14:43+00:00

Use fbdev's DMA helpers for fbdev emulation. The driver previously
used the I/O-memory helpers, while allocating DMA-able system memory.
This could (in theory) result in bus errors from accessing the memory
range.

This bug has been present since the exynos driver was first added.

v2:
	* drop the pointless Fixes tag (Javier)
	* fix typo in commit message

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
Acked-by: Inki Dae 
Acked-by: Maxime Ripard 
Cc: Inki Dae 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Cc: Krzysztof Kozlowski 
Cc: Alim Akhtar 
Link: https://patchwork.freedesktop.org/patch/msgid/20230707083422.18691-7-tzimmermann@suse.de

Merge drm/drm-next into drm-misc-next

2023-07-24T13:44:47+00:00

Backmerging to get v6.5-rc2.

Signed-off-by: Thomas Zimmermann