kernel/linux.git/drivers/gpu/drm/udl, branch v6.19.11

drm: include drm_print.h where needed

2025-10-31T08:34:52+00:00

There are a gazillion files that depend on drm_print.h being indirectly included via drm_buddy.h, drm_mm.h, or ttm/ttm_resource.h. In preparation for removing those includes, explicitly include drm_print.h where needed. Cc: Thomas Zimmermann Reviewed-by: Thomas Zimmermann Signed-off-by: Jani Nikula Link: https://lore.kernel.org/r/5fe67395907be33eb5199ea6d540e29fddee71c8.1761734313.git.jani.nikula@intel.com

drm/gem-shmem: Do not map s/g table by default

2025-07-07T13:23:41+00:00

The vast majority of drivers that use GEM-SHMEM helpers do not use an s/g table for imported buffers; specifically all drivers that use DRM_GEM_SHMEM_DRIVER_OPS. Therefore convert the initializer macro to DRM_GEM_SHMEM_DRIVER_OPS_NO_MAP_SGT and remove the latter. This helps to avoid swiotbl errors, such as seen with some Aspeed systems ast 0000:07:00.0: swiotlb buffer is full (sz: 3145728 bytes), total 32768 (slots), used 0 (slots) The error is caused by the system's limited DMA capabilities and can happen with any GEM-SHMEM-based driver. It results in a performance penalty. In the case of vgem and vkms, the devices do not support DMA at all, which can result in failure to map the buffer object into the kernel's address space. [1][2] Avoiding the s/g table fixes this problem. The other drivers based on GEM-SHMEM, imagination, lima, panfrost, panthor, v3d and virtio, use the s/g table of imported buffers. Neither driver uses the default initializer, so they won't be affected by this change. Signed-off-by: Thomas Zimmermann Reported-by: Zenghui Yu Closes: https://lore.kernel.org/dri-devel/6d22bce3-4533-4cfa-96ba-64352b715741@linux.dev/ # [1] Reported-by: José Expósito Closes: https://lore.kernel.org/dri-devel/20250311172054.2903-1-jose.exposito89@gmail.com/ # [2] Tested-by: Zenghui Yu Reviewed-by: Christian König Reviewed-by: Louis Chauvet Link: https://lore.kernel.org/r/20250630143537.309052-1-tzimmermann@suse.de

drm/udl: use DRM_GEM_SHMEM_DRIVER_OPS_NO_MAP_SGT

2025-06-03T07:21:02+00:00

Import dmabuf without mapping its sg_table to avoid issues likes: udl 2-1.4:1.0: swiotlb buffer is full (sz: 2097152 bytes), total 65536 (slots), used 1 (slots) Signed-off-by: Shixiong Ou Reviewed-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Link: https://lore.kernel.org/r/20250522070714.439824-3-oushixiong1025@163.com

drm/udl: Set error code in udl_init()

2025-04-17T08:21:40+00:00

Return -ENOMEM if udl_alloc_urb_list() fails. Don't return success. Fixes: fb10144ba426 ("drm/udl: Support adapters without firmware descriptor") Signed-off-by: Dan Carpenter Reviewed-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Link: https://lore.kernel.org/r/Z_-P4N4_U-xTC9-O@stanley.mountain

drm/udl: Support adapters without firmware descriptor

2025-04-14T08:19:21+00:00

Set default limit on the number of pixels for adapters without vendor firmware descriptor. The devices work as expected, they just don't provide any description. If parsing the vendor firmware descriptor fails, the device falls back to the given default limits. Failing to allocate memory is still an error. v2: - fix typo in constant (Patrik) Signed-off-by: Thomas Zimmermann Reviewed-by: Patrik Jakobsson Link: https://lore.kernel.org/r/20250410105948.25463-10-tzimmermann@suse.de

drm/udl: Validate length in vendor-descriptor parser

2025-04-14T08:19:20+00:00

Rewrite the parser for the vendor firmware descriptor with the following improvements. - Validate the key-value length given in a vendor descriptor against the length of the descriptor. The current code fails to do this and might read more bytes than available. This can lead to out-of-bounds reads of the allocated buffer. - Read raw data with helpers for unaligned data. This allows the code to run on platforms that do now support unaligned memory access by default. - Validate the pixel limit against a default value. The default comes from real-world devices. If the reported number of pixels is significantly above the limit, it is likely invalid. - Drop the obsolete print macros. There is still a warning about invalid firmware descriptors. The rest of the output is bogus. Signed-off-by: Thomas Zimmermann Reviewed-by: Patrik Jakobsson Link: https://lore.kernel.org/r/20250410105948.25463-9-tzimmermann@suse.de

drm/udl: Treat vendor descriptor as u8

2025-04-14T08:19:20+00:00

The vendor descriptor is an array of unsigned bytes. It is raw data that is not to be modified. Declare it as 'const u8'. Signed-off-by: Thomas Zimmermann Reviewed-by: Patrik Jakobsson Link: https://lore.kernel.org/r/20250410105948.25463-8-tzimmermann@suse.de

drm/udl: Return error if vendor descriptor is too short

2025-04-14T08:19:19+00:00

There need to be least 5 bytes in the vendor descriptor. Return an error otherwise. Also change the branching to early-out on the error. Adjust indention of the rest of the parser function. The original length test expected more than 5 bytes in the vendor descriptor. As a descriptor with no key-value pairs has exactly 5 bytes and is still valid, change the test to accept this case as well. v2 - clarify changes to length test in commit description (Patrik) Signed-off-by: Thomas Zimmermann Reviewed-by: Patrik Jakobsson Link: https://lore.kernel.org/r/20250410105948.25463-7-tzimmermann@suse.de

drm/udl: Handle errors from usb_get_descriptor()

2025-04-14T08:19:19+00:00

Reading the vendor descriptor from the udl device can fail with an error, which the current code fails to capture. Store the return value in an integer and test for the error. Abort parsing on errors or treat the value as length on success. Signed-off-by: Thomas Zimmermann Reviewed-by: Patrik Jakobsson Link: https://lore.kernel.org/r/20250410105948.25463-6-tzimmermann@suse.de

drm/udl: The number of pixels is always positive

2025-04-14T08:19:18+00:00

Store sku_pixel_limit as type unsigned long instead of int. The number of pixels available is always positive. Signed-off-by: Thomas Zimmermann Reviewed-by: Patrik Jakobsson Link: https://lore.kernel.org/r/20250410105948.25463-5-tzimmermann@suse.de