linux-stable.git/drivers/gpu/drm/tiny, branch linux-5.10.y

drm/repaper: fix integer overflows in repeat functions

2025-05-02T05:41:03+00:00

commit 4d098000ac193f359e6b8ca4801dbdbd6a27b41f upstream.

There are conditions, albeit somewhat unlikely, under which right hand
expressions, calculating the end of time period in functions like
repaper_frame_fixed_repeat(), may overflow.

For instance, if 'factor10x' in repaper_get_temperature() is high
enough (170), as is 'epd->stage_time' in repaper_probe(), then the
resulting value of 'end' will not fit in unsigned int expression.

Mitigate this by casting 'epd->factored_stage_time' to wider type before
any multiplication is done.

Found by Linux Verification Center (linuxtesting.org) with static
analysis tool SVACE.

Fixes: 3589211e9b03 ("drm/tinydrm: Add RePaper e-ink driver")
Cc: stable@vger.kernel.org
Signed-off-by: Nikita Zhandarovich 
Signed-off-by: Alex Lanzano 
Link: https://patchwork.freedesktop.org/patch/msgid/20250116134801.22067-1-n.zhandarovich@fintech.ru
Signed-off-by: Greg Kroah-Hartman

drm: gm12u320: Fix the timeout usage for usb_bulk_msg()

2023-09-23T09:01:09+00:00

[ Upstream commit 7583028d359db3cd0072badcc576b4f9455fd27a ]

The timeout arg of usb_bulk_msg() is ms already, which has been converted
to jiffies by msecs_to_jiffies() in usb_start_wait_urb(). So fix the usage
by removing the redundant msecs_to_jiffies() in the macros.

And as Hans suggested, also remove msecs_to_jiffies() for the IDLE_TIMEOUT
macro to make it consistent here and so change IDLE_TIMEOUT to
msecs_to_jiffies(IDLE_TIMEOUT) where it is used.

Fixes: e4f86e437164 ("drm: Add Grain Media GM12U320 driver v2")
Signed-off-by: Jinjie Ruan 
Suggested-by: Hans de Goede 
Reviewed-by: Hans de Goede 
Signed-off-by: Thomas Zimmermann 
Link: https://patchwork.freedesktop.org/patch/msgid/20230904021421.1663892-1-ruanjinjie@huawei.com
Signed-off-by: Sasha Levin

drm/tiny: ili9486: Do not assume 8-bit only SPI controllers

2023-03-11T15:39:52+00:00

[ Upstream commit 77772e607522daa61f3af74df018559db75c43d6 ]

The pixel data for the ILI9486 is always 16-bits wide and it must be
sent over the SPI bus. When the controller is only able to deal with
8-bit transfers, this 16-bits data needs to be swapped before the
sending to account for the big endian bus, this is on the contrary not
needed when the SPI controller already supports 16-bits transfers.

The decision about swapping the pixel data or not is taken in the MIPI
DBI code by probing the controller capabilities: if the controller only
suppors 8-bit transfers the data is swapped, otherwise it is not.

This swapping/non-swapping is relying on the assumption that when the
controller does support 16-bit transactions then the data is sent
unswapped in 16-bits-per-word over SPI.

The problem with the ILI9486 driver is that it is forcing 8-bit
transactions also for controllers supporting 16-bits, violating the
assumption and corrupting the pixel data.

Align the driver to what is done in the MIPI DBI code by adjusting the
transfer size to the maximum allowed by the SPI controller.

Reviewed-by: Neil Armstrong 
Signed-off-by: Carlo Caione 
Reviewed-by: Kamlesh Gurudasani 
Signed-off-by: Neil Armstrong 
Link: https://patchwork.freedesktop.org/patch/msgid/20221116-s905x_spi_ili9486-v4-2-f86b4463b9e4@baylibre.com
Signed-off-by: Sasha Levin

drm/st7735r: Fix module autoloading for Okaya RH128128T

2022-08-21T13:15:38+00:00

[ Upstream commit 9ad6f181ad9a19a26bda73a7b199df44ccfcdaba ]

The SPI core always reports a "MODALIAS=spi:", even if the device was
registered via OF. This means that the st7735r.ko module won't autoload if
a DT has a node with a compatible "okaya,rh128128t" string.

In that case, kmod expects a "MODALIAS=of:N*T*Cokaya,rh128128t" uevent but
instead will get a "MODALIAS=spi:rh128128t", which is not present in the
list of aliases:

  $ modinfo drivers/gpu/drm/tiny/st7735r.ko | grep alias
  alias:          of:N*T*Cokaya,rh128128tC*
  alias:          of:N*T*Cokaya,rh128128t
  alias:          of:N*T*Cjianda,jd-t18003-t01C*
  alias:          of:N*T*Cjianda,jd-t18003-t01
  alias:          spi:jd-t18003-t01

To workaround this issue, add in the SPI table an entry for that device.

Fixes: d1d511d516f7 ("drm: tiny: st7735r: Add support for Okaya RH128128T")
Signed-off-by: Javier Martinez Canillas 
Reviewed-by: Geert Uytterhoeven 
Acked-by: David Lechner 
Link: https://patchwork.freedesktop.org/patch/msgid/20220520091602.179078-1-javierm@redhat.com
Signed-off-by: Sasha Levin

drm: Use USB controller's DMA mask when importing dmabufs

2021-03-17T16:06:19+00:00

commit 659ab7a49cbebe0deffcbe1f9560e82006b21817 upstream.

USB devices cannot perform DMA and hence have no dma_mask set in their
device structure. Therefore importing dmabuf into a USB-based driver
fails, which breaks joining and mirroring of display in X11.

For USB devices, pick the associated USB controller as attachment device.
This allows the DRM import helpers to perform the DMA setup. If the DMA
controller does not support DMA transfers, we're out of luck and cannot
import. Our current USB-based DRM drivers don't use DMA, so the actual
DMA device is not important.

Tested by joining/mirroring displays of udl and radeon under Gnome/X11.

v8:
	* release dmadev if device initialization fails (Noralf)
	* fix commit description (Noralf)
v7:
	* fix use-before-init bug in gm12u320 (Dan)
v6:
	* implement workaround in DRM drivers and hold reference to
	  DMA device while USB device is in use
	* remove dev_is_usb() (Greg)
	* collapse USB helper into usb_intf_get_dma_device() (Alan)
	* integrate Daniel's TODO statement (Daniel)
	* fix typos (Greg)
v5:
	* provide a helper for USB interfaces (Alan)
	* add FIXME item to documentation and TODO list (Daniel)
v4:
	* implement workaround with USB helper functions (Greg)
	* use struct usb_device->bus->sysdev as DMA device (Takashi)
v3:
	* drop gem_create_object
	* use DMA mask of USB controller, if any (Daniel, Christian, Noralf)
v2:
	* move fix to importer side (Christian, Daniel)
	* update SHMEM and CMA helpers for new PRIME callbacks

Signed-off-by: Thomas Zimmermann 
Fixes: 6eb0233ec2d0 ("usb: don't inherity DMA properties for USB devices")
Tested-by: Pavel Machek 
Reviewed-by: Greg Kroah-Hartman 
Acked-by: Christian König 
Acked-by: Daniel Vetter 
Acked-by: Noralf Trønnes 
Cc: Christoph Hellwig 
Cc: Greg Kroah-Hartman 
Cc:  # v5.10+
Signed-off-by: Thomas Zimmermann 
Link: https://patchwork.freedesktop.org/patch/msgid/20210303133229.3288-1-tzimmermann@suse.de
Signed-off-by: Maarten Lankhorst 
Signed-off-by: Greg Kroah-Hartman

drm/mipi-dbi: Remove ->enabled

2020-06-24T07:17:34+00:00

The atomic helpers try really hard to not lose track of things,
duplicating enabled tracking in the driver is at best confusing.
Double-enabling or disabling is a bug in atomic helpers.

In the fb_dirty function we can just assume that the fb always exists,
simple display pipe helpers guarantee that the crtc is only enabled
together with the output, so we always have a primary plane around.

Now in the update function we need to be a notch more careful, since
that can also get called when the crtc is off. And we don't want to
upload frames when that's the case, so filter that out too.

Reviewed-by: Noralf Trønnes 
Acked-by: David Lechner 
Reviewed-by: Emil Velikov 
Signed-off-by: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: David Lechner 
Link: https://patchwork.freedesktop.org/patch/msgid/20200612160056.2082681-7-daniel.vetter@ffwll.ch

drm/tiny/repaper: Drop edp->enabled

2020-06-24T07:17:30+00:00

Same patch as the mipi-dbi one, atomic tracks this for us already, we
just have to check the right thing.

Reviewed-by: Noralf Trønnes 
Reviewed-by: Emil Velikov 
Signed-off-by: Daniel Vetter 
Cc: "Noralf Trønnes" 
Link: https://patchwork.freedesktop.org/patch/msgid/20200612160056.2082681-8-daniel.vetter@ffwll.ch

drm/cma-helper: Rework DRM_GEM_CMA_VMAP_DRIVER_OPS macro

2020-06-10T07:01:41+00:00

Rename the macro to DRM_GEM_CMA_DRIVER_OPS_VMAP to align naming with
SHMEM helpers and drm_gem_cma_prime_import_sg_table_vmap(). An variant of
the macro is provided for drivers that override the default .dumb_create
callback. Adapt drivers to the changes.

v3:
	* rename macro to signal implicit vmap on imported buffers
v2:
	* provide DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Sam Ravnborg 
Reviewed-by: Laurent Pinchart 
Reviewed-by: Emil Velikov 
Link: https://patchwork.freedesktop.org/patch/msgid/20200605073247.4057-3-tzimmermann@suse.de

drm/cirrus: Move to drm/tiny

2020-04-28T14:05:15+00:00

Because it is. Huge congrats to everyone who made this kind of
refactoring happen!

Acked-by: Gerd Hoffmann 
Reviewed-by: Thomas Zimmermann 
Acked-by: Sam Ravnborg 
Signed-off-by: Daniel Vetter 
Cc: Dave Airlie 
Cc: Gerd Hoffmann 
Cc: virtualization@lists.linux-foundation.org
Link: https://patchwork.freedesktop.org/patch/msgid/20200415074034.175360-38-daniel.vetter@ffwll.ch

drm/gm12u320: Don't use drm_device->dev_private

2020-04-28T13:55:19+00:00

Upcasting using a container_of macro is more typesafe, faster and
easier for the compiler to optimize.

Acked-by: Sam Ravnborg 
Reviewed-by: Hans de Goede 
Signed-off-by: Daniel Vetter 
Cc: Hans de Goede 
Link: https://patchwork.freedesktop.org/patch/msgid/20200415074034.175360-23-daniel.vetter@ffwll.ch