lwn.git/drivers/gpu/drm/drm_drv.c, branch alabaster

drm: fix null-ptr-deref in drm_dev_init_release()

2021-10-14T19:39:02+00:00

I got a null-ptr-deref report: [drm:drm_dev_init [drm]] *ERROR* Cannot allocate anonymous inode: -12 ================================================================== BUG: KASAN: null-ptr-deref in iput+0x3c/0x4a0 ... Call Trace: dump_stack_lvl+0x6c/0x8b kasan_report.cold+0x64/0xdb __asan_load8+0x69/0x90 iput+0x3c/0x4a0 drm_dev_init_release+0x39/0xb0 [drm] drm_managed_release+0x158/0x2d0 [drm] drm_dev_init+0x3a7/0x4c0 [drm] __devm_drm_dev_alloc+0x55/0xd0 [drm] mi0283qt_probe+0x8a/0x2b5 [mi0283qt] spi_probe+0xeb/0x130 ... entry_SYSCALL_64_after_hwframe+0x44/0xae If drm_fs_inode_new() fails in drm_dev_init(), dev->anon_inode will point to PTR_ERR(...) instead of NULL. This will result in null-ptr-deref when drm_fs_inode_free(dev->anon_inode) is called. drm_dev_init() drm_fs_inode_new() // fail, dev->anon_inode = PTR_ERR(...) drm_managed_release() drm_dev_init_release() drm_fs_inode_free() // access non-existent anon_inode Define a temp variable and assign it to dev->anon_inode if the temp variable is not PTR_ERR. Fixes: 2cbf7fc6718b ("drm: Use drmm_ for drm_dev_init cleanup") Reported-by: Hulk Robot Signed-off-by: Wang Hai Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20211013114139.4042207-1-wanghai38@huawei.com

drm: Add privacy-screen class (v4)

2021-10-14T11:12:21+00:00

On some new laptops the LCD panel has a builtin electronic privacy-screen. We want to export this functionality as a property on the drm connector object. But often this functionality is not exposed on the GPU but on some other (ACPI) device. This commit adds a privacy-screen class allowing the driver for these other devices to register themselves as a privacy-screen provider; and allowing the drm/kms code to get a privacy-screen provider associated with a specific GPU/connector combo. Changes in v2: - Make CONFIG_DRM_PRIVACY_SCREEN a bool which controls if the drm_privacy code gets built as part of the main drm module rather then making it a tristate which builds its own module. - Add a #if IS_ENABLED(CONFIG_DRM_PRIVACY_SCREEN) check to drm_privacy_screen_consumer.h and define stubs when the check fails. Together these 2 changes fix several dependency issues. - Remove module related code now that this is part of the main drm.ko - Use drm_class as class for the privacy-screen devices instead of adding a separate class for this Changes in v3: - Make the static inline drm_privacy_screen_get_state() stub set sw_state and hw_state to PRIVACY_SCREEN_DISABLED to squelch an uninitialized variable warning when CONFIG_DRM_PRIVICAY_SCREEN is not set Changes in v4: - Make drm_privacy_screen_set_sw_state() skip calling out to the hw if hw_state == new_sw_state Reviewed-by: Emil Velikov Reviewed-by: Lyude Paul Signed-off-by: Hans de Goede Link: https://patchwork.freedesktop.org/patch/msgid/20211005202322.700909-3-hdegoede@redhat.com

drm: Fix typo in comments

2021-08-02T08:19:43+00:00

fix typo for drm v1->v2: respin with the change "iff ==> implies that" Signed-off-by: Cai Huoqing Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210730132729.376-1-caihuoqing@baidu.com

drm: Add a prefetching memcpy_from_wc

2021-06-07T14:07:08+00:00

Reading out of write-combining mapped memory is typically very slow since the CPU doesn't prefetch. However some archs have special instructions to do this. So add a best-effort memcpy_from_wc taking dma-buf-map pointer arguments that attempts to use a fast prefetching memcpy and otherwise falls back to ordinary memcopies, taking the iomem tagging into account. The code is largely copied from i915_memcpy_from_wc. Cc: Daniel Vetter Cc: Christian König Suggested-by: Daniel Vetter Signed-off-by: Thomas Hellström Acked-by: Christian König Acked-by: Daniel Vetter Link: https://lore.kernel.org/r/20210602083818.241793-5-thomas.hellstrom@linux.intel.com Link: https://patchwork.freedesktop.org/patch/msgid/20210602083818.241793-5-thomas.hellstrom@linux.intel.com

drm: Mark PCI AGP helpers as legacy

2021-05-10T13:46:54+00:00

DRM's AGP helpers for PCI are only required by legacy drivers. Put them behind CONFIG_DRM_LEGACY and add the _legacy_ infix. Signed-off-by: Thomas Zimmermann Reviewed-by: Alex Deucher Acked-by: Christian König Link: https://patchwork.freedesktop.org/patch/msgid/20210507185709.22797-4-tzimmermann@suse.de

drm/drv: Remove initialization of static variables

2021-02-22T00:49:17+00:00

Address the following checkpatch errors: ERROR: do not initialise statics to false Signed-off-by: Tian Tao Acked-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/1613701811-32037-1-git-send-email-tiantao6@hisilicon.com

drm: Unamp the entire device address space on device unplug

2021-01-19T09:22:14+00:00

Invalidate all BOs CPU mappings once device is removed. v3: Move the code from TTM into drm_dev_unplug Signed-off-by: Andrey Grodzovsky Reviewed-by: Christian König Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/414809/ Signed-off-by: Christian König

Merge tag 'du-next-20210105' of git://linuxtv.org/pinchartl/media into drm-next

2021-01-07T12:02:57+00:00

- Add default modes for connectors in unknown state - R-Car DU conversion to DRM-managed API - R-Car DU miscellaneous fixes - Miscellaneous bridge and bridge bindings fixes - Assorted misc driver cleanups - Constify drm_driver for PCI devices Signed-off-by: Daniel Vetter From: Laurent Pinchart Link: https://patchwork.freedesktop.org/patch/msgid/X/P8IOrVXkTpLeCm@pendragon.ideasonboard.com

drm: Use a const drm_driver for legacy PCI devices

2021-01-05T05:20:35+00:00

Now that the legacy PCI support code doesn't need to write to the drm_driver structure, it can be treated as const through the whole DRM core, unconditionally. This allows declaring the structure as const in all drivers, removing one possible attack vector. Signed-off-by: Laurent Pinchart Reviewed-by: Daniel Vetter

drm/drv: Remove invalid assignments

2020-12-14T06:57:27+00:00

it's not necessary to assign a value of 0 to ret here, because if the previous functions were executed correctly, ret would be 0. Signed-off-by: Tian Tao Reviewed-by: Simon Ser Link: https://patchwork.freedesktop.org/patch/msgid/1607653037-37785-1-git-send-email-tiantao6@hisilicon.com