- 27 Sep, 2022 2 commits
-
-
Thomas Zimmermann authored
Lookup the plane's state in atomic_update with the helper drm_atomic_get_new_plane_state(). Also rename the helpers' state arguments. No functional changes. Suggested-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Michael J. Ruhl <michael.j.ruhl@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220922130944.27138-3-tzimmermann@suse.de
-
Thomas Zimmermann authored
If not given, compute the stride with drm_format_info_min_pitch(). It's the standard helper for this purpose. Suggested-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
- 26 Sep, 2022 3 commits
-
-
Sean Hong authored
Add support for the INX - N116BCA-EA2 (HW: C1) panel Signed-off-by:
Sean Hong <sean.hong@quanta.corp-partner.google.com> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
Christian König authored
Let's make sure nobody is calling those functions without holding the appropriate locks. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220715111533.467012-2-christian.koenig@amd.com
-
ruanjinjie authored
The symbol is not used outside of the file, so mark it static. Fixes the following warning: drivers/gpu/drm/ast/ast_drv.c:42:5: warning: symbol 'ast_modeset' was not declared. Should it be static? Signed-off-by:
ruanjinjie <ruanjinjie@huawei.com> Signed-off-by:
-
- 23 Sep, 2022 10 commits
-
-
Sean Hong authored
Add support for the AUO - B116XAK01.6 (HW: 1A) panel. Signed-off-by:
-
Sean Hong authored
Add support for the BOE - NT116WHM-N21 (HW: V8.2) panel. Signed-off-by:
-
Sean Hong authored
Add support for the BOE - NT116WHM-N21 (HW: V8.1) panel. Signed-off-by:
-
Sean Hong authored
Add support for the INX - N116BCN-EA1 (HW: C4) panel. Signed-off-by:
-
Dan Carpenter authored
The ->ring_idx_mask variable is a u64 so static checkers, Smatch in this case, complain if the BIT() is not also a u64. drivers/gpu/drm/virtio/virtgpu_ioctl.c:50 virtio_gpu_fence_event_create() warn: should '(1 << ring_idx)' be a 64 bit type? Fixes: cd7f5ca3 ("drm/virtio: implement context init: add virtio_gpu_fence_event") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Chia-I Wu <olvaffe@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/YygN7jY0GdUSQSy0@kiliSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
Zongmin Zhou authored
Since qxl_io_reset(qdev) will be called immediately after qxl_ring_create() been called, and parameter like notify_on_prod will be set to default value. So the call to qxl_ring_init_hdr() before becomes meaningless. Signed-off-by: Zongmin Zhou<zhouzongmin@kylinos.cn> Suggested-by: Ming Xie<xieming@kylinos.cn> Link: http://patchwork.freedesktop.org/patch/msgid/20220920065023.1633303-1-zhouzongmin@kylinos.cnSigned-off-by:
-
Adrián Larumbe authored
drm bridges added by meson_encoder_hdmi_init and meson_encoder_cvbs_init were not manually removed at module unload time, which caused dangling references to freed memory to remain linked in the global bridge_list. When loading the driver modules back in, the same functions would again call drm_bridge_add, and when traversing the global bridge_list, would end up peeking into freed memory. Once again KASAN revealed the problem: [ +0.000095] ============================================================= [ +0.000008] BUG: KASAN: use-after-free in __list_add_valid+0x9c/0x120 [ +0.000018] Read of size 8 at addr ffff00003da291f0 by task modprobe/2483 [ +0.000018] CPU: 3 PID: 2483 Comm: modprobe Tainted: G C O 5.19.0-rc6-lrmbkasan+ #1 [ +0.000011] Hardware name: Hardkernel ODROID-N2Plus (DT) [ +0.000008] Call trace: [ +0.000006] dump_backtrace+0x1ec/0x280 [ +0.000012] show_stack+0x24/0x80 [ +0.000008] dump_stack_lvl+0x98/0xd4 [ +0.000011] print_address_description.constprop.0+0x80/0x520 [ +0.000011] print_report+0x128/0x260 [ +0.000008] kasan_report+0xb8/0xfc [ +0.000008] __asan_report_load8_noabort+0x3c/0x50 [ +0.000009] __list_add_valid+0x9c/0x120 [ +0.000009] drm_bridge_add+0x6c/0x104 [drm] [ +0.000165] dw_hdmi_probe+0x1900/0x2360 [dw_hdmi] [ +0.000022] meson_dw_hdmi_bind+0x520/0x814 [meson_dw_hdmi] [ +0.000014] component_bind+0x174/0x520 [ +0.000012] component_bind_all+0x1a8/0x38c [ +0.000010] meson_drv_bind_master+0x5e8/0xb74 [meson_drm] [ +0.000032] meson_drv_bind+0x20/0x2c [meson_drm] [ +0.000027] try_to_bring_up_aggregate_device+0x19c/0x390 [ +0.000010] component_master_add_with_match+0x1c8/0x284 [ +0.000009] meson_drv_probe+0x274/0x280 [meson_drm] [ +0.000026] platform_probe+0xd0/0x220 [ +0.000009] really_probe+0x3ac/0xa80 [ +0.000009] __driver_probe_device+0x1f8/0x400 [ +0.000009] driver_probe_device+0x68/0x1b0 [ +0.000009] __driver_attach+0x20c/0x480 [ +0.000008] bus_for_each_dev+0x114/0x1b0 [ +0.000009] driver_attach+0x48/0x64 [ +0.000008] bus_add_driver+0x390/0x564 [ +0.000009] driver_register+0x1a8/0x3e4 [ +0.000009] __platform_driver_register+0x6c/0x94 [ +0.000008] meson_drm_platform_driver_init+0x3c/0x1000 [meson_drm] [ +0.000027] do_one_initcall+0xc4/0x2b0 [ +0.000011] do_init_module+0x154/0x570 [ +0.000011] load_module+0x1a78/0x1ea4 [ +0.000008] __do_sys_init_module+0x184/0x1cc [ +0.000009] __arm64_sys_init_module+0x78/0xb0 [ +0.000009] invoke_syscall+0x74/0x260 [ +0.000009] el0_svc_common.constprop.0+0xcc/0x260 [ +0.000008] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000012] el0t_64_sync_handler+0x11c/0x150 [ +0.000008] el0t_64_sync+0x18c/0x190 [ +0.000016] Allocated by task 879: [ +0.000008] kasan_save_stack+0x2c/0x5c [ +0.000011] __kasan_kmalloc+0x90/0xd0 [ +0.000007] __kmalloc+0x278/0x4a0 [ +0.000011] mpi_resize+0x13c/0x1d0 [ +0.000011] mpi_powm+0xd24/0x1570 [ +0.000009] rsa_enc+0x1a4/0x30c [ +0.000009] pkcs1pad_verify+0x3f0/0x580 [ +0.000009] public_key_verify_signature+0x7a8/0xba4 [ +0.000010] public_key_verify_signature_2+0x40/0x60 [ +0.000008] verify_signature+0xb4/0x114 [ +0.000008] pkcs7_validate_trust_one.constprop.0+0x3b8/0x574 [ +0.000009] pkcs7_validate_trust+0xb8/0x15c [ +0.000008] verify_pkcs7_message_sig+0xec/0x1b0 [ +0.000012] verify_pkcs7_signature+0x78/0xac [ +0.000007] mod_verify_sig+0x110/0x190 [ +0.000009] module_sig_check+0x114/0x1e0 [ +0.000009] load_module+0xa0/0x1ea4 [ +0.000008] __do_sys_init_module+0x184/0x1cc [ +0.000008] __arm64_sys_init_module+0x78/0xb0 [ +0.000008] invoke_syscall+0x74/0x260 [ +0.000009] el0_svc_common.constprop.0+0x1a8/0x260 [ +0.000008] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000009] el0t_64_sync_handler+0x11c/0x150 [ +0.000009] el0t_64_sync+0x18c/0x190 [ +0.000013] Freed by task 2422: [ +0.000008] kasan_save_stack+0x2c/0x5c [ +0.000009] kasan_set_track+0x2c/0x40 [ +0.000007] kasan_set_free_info+0x28/0x50 [ +0.000009] ____kasan_slab_free+0x128/0x1d4 [ +0.000008] __kasan_slab_free+0x18/0x24 [ +0.000007] slab_free_freelist_hook+0x108/0x230 [ +0.000010] kfree+0x110/0x35c [ +0.000008] release_nodes+0xf0/0x16c [ +0.000009] devres_release_group+0x180/0x270 [ +0.000008] take_down_aggregate_device+0xcc/0x160 [ +0.000010] component_del+0x18c/0x360 [ +0.000009] meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi] [ +0.000013] platform_remove+0x64/0xb0 [ +0.000008] device_remove+0xb8/0x154 [ +0.000009] device_release_driver_internal+0x398/0x5b0 [ +0.000009] driver_detach+0xac/0x1b0 [ +0.000009] bus_remove_driver+0x158/0x29c [ +0.000008] driver_unregister+0x70/0xb0 [ +0.000009] platform_driver_unregister+0x20/0x2c [ +0.000007] meson_dw_hdmi_platform_driver_exit+0x1c/0x30 [meson_dw_hdmi] [ +0.000012] __do_sys_delete_module+0x288/0x400 [ +0.000009] __arm64_sys_delete_module+0x5c/0x80 [ +0.000009] invoke_syscall+0x74/0x260 [ +0.000008] el0_svc_common.constprop.0+0xcc/0x260 [ +0.000008] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000008] el0t_64_sync_handler+0x11c/0x150 [ +0.000009] el0t_64_sync+0x18c/0x190 [ +0.000013] The buggy address belongs to the object at ffff00003da29000 which belongs to the cache kmalloc-1k of size 1024 [ +0.000008] The buggy address is located 496 bytes inside of 1024-byte region [ffff00003da29000, ffff00003da29400) [ +0.000015] The buggy address belongs to the physical page: [ +0.000009] page:fffffc0000f68a00 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x3da28 [ +0.000012] head:fffffc0000f68a00 order:3 compound_mapcount:0 compound_pincount:0 [ +0.000009] flags: 0xffff00000010200(slab|head|node=0|zone=0|lastcpupid=0xffff) [ +0.000019] raw: 0ffff00000010200 fffffc0000eb5c08 fffffc0000d96608 ffff000000002a80 [ +0.000008] raw: 0000000000000000 00000000000a000a 00000001ffffffff 0000000000000000 [ +0.000008] page dumped because: kasan: bad access detected [ +0.000011] Memory state around the buggy address: [ +0.000009] ffff00003da29080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000007] ffff00003da29100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000007] >ffff00003da29180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000007] ^ [ +0.000008] ffff00003da29200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000006] ffff00003da29280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000007] ================================================================== Fix by keeping track of which encoders were initialised in the meson_drm structure and manually removing their bridges at aggregate driver's unbind time. Signed-off-by:Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by:
Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by:
-
Adrián Larumbe authored
Because component_master_del wasn't being called when unloading the meson_drm module, the aggregate device would linger forever in the global aggregate_devices list. That means when unloading and reloading the meson_dw_hdmi module, component_add would call into try_to_bring_up_aggregate_device and find the unbound meson_drm aggregate device. This would in turn dereference some of the aggregate_device's struct entries which point to memory automatically freed by the devres API when unbinding the aggregate device from meson_drv_unbind, and trigger an use-after-free bug: [ +0.000014] ============================================================= [ +0.000007] BUG: KASAN: use-after-free in find_components+0x468/0x500 [ +0.000017] Read of size 8 at addr ffff000006731688 by task modprobe/2536 [ +0.000018] CPU: 4 PID: 2536 Comm: modprobe Tainted: G C O 5.19.0-rc6-lrmbkasan+ #1 [ +0.000010] Hardware name: Hardkernel ODROID-N2Plus (DT) [ +0.000008] Call trace: [ +0.000005] dump_backtrace+0x1ec/0x280 [ +0.000011] show_stack+0x24/0x80 [ +0.000007] dump_stack_lvl+0x98/0xd4 [ +0.000010] print_address_description.constprop.0+0x80/0x520 [ +0.000011] print_report+0x128/0x260 [ +0.000007] kasan_report+0xb8/0xfc [ +0.000007] __asan_report_load8_noabort+0x3c/0x50 [ +0.000009] find_components+0x468/0x500 [ +0.000008] try_to_bring_up_aggregate_device+0x64/0x390 [ +0.000009] __component_add+0x1dc/0x49c [ +0.000009] component_add+0x20/0x30 [ +0.000008] meson_dw_hdmi_probe+0x28/0x34 [meson_dw_hdmi] [ +0.000013] platform_probe+0xd0/0x220 [ +0.000008] really_probe+0x3ac/0xa80 [ +0.000008] __driver_probe_device+0x1f8/0x400 [ +0.000008] driver_probe_device+0x68/0x1b0 [ +0.000008] __driver_attach+0x20c/0x480 [ +0.000009] bus_for_each_dev+0x114/0x1b0 [ +0.000007] driver_attach+0x48/0x64 [ +0.000009] bus_add_driver+0x390/0x564 [ +0.000007] driver_register+0x1a8/0x3e4 [ +0.000009] __platform_driver_register+0x6c/0x94 [ +0.000007] meson_dw_hdmi_platform_driver_init+0x30/0x1000 [meson_dw_hdmi] [ +0.000014] do_one_initcall+0xc4/0x2b0 [ +0.000008] do_init_module+0x154/0x570 [ +0.000010] load_module+0x1a78/0x1ea4 [ +0.000008] __do_sys_init_module+0x184/0x1cc [ +0.000008] __arm64_sys_init_module+0x78/0xb0 [ +0.000008] invoke_syscall+0x74/0x260 [ +0.000008] el0_svc_common.constprop.0+0xcc/0x260 [ +0.000009] do_el0_svc+0x50/0x70 [ +0.000008] el0_svc+0x68/0x1a0 [ +0.000009] el0t_64_sync_handler+0x11c/0x150 [ +0.000009] el0t_64_sync+0x18c/0x190 [ +0.000014] Allocated by task 902: [ +0.000007] kasan_save_stack+0x2c/0x5c [ +0.000009] __kasan_kmalloc+0x90/0xd0 [ +0.000007] __kmalloc_node+0x240/0x580 [ +0.000010] memcg_alloc_slab_cgroups+0xa4/0x1ac [ +0.000010] memcg_slab_post_alloc_hook+0xbc/0x4c0 [ +0.000008] kmem_cache_alloc_node+0x1d0/0x490 [ +0.000009] __alloc_skb+0x1d4/0x310 [ +0.000010] alloc_skb_with_frags+0x8c/0x620 [ +0.000008] sock_alloc_send_pskb+0x5ac/0x6d0 [ +0.000010] unix_dgram_sendmsg+0x2e0/0x12f0 [ +0.000010] sock_sendmsg+0xcc/0x110 [ +0.000007] sock_write_iter+0x1d0/0x304 [ +0.000008] new_sync_write+0x364/0x460 [ +0.000007] vfs_write+0x420/0x5ac [ +0.000008] ksys_write+0x19c/0x1f0 [ +0.000008] __arm64_sys_write+0x78/0xb0 [ +0.000007] invoke_syscall+0x74/0x260 [ +0.000008] el0_svc_common.constprop.0+0x1a8/0x260 [ +0.000009] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000008] el0t_64_sync_handler+0x11c/0x150 [ +0.000008] el0t_64_sync+0x18c/0x190 [ +0.000013] Freed by task 2509: [ +0.000008] kasan_save_stack+0x2c/0x5c [ +0.000007] kasan_set_track+0x2c/0x40 [ +0.000008] kasan_set_free_info+0x28/0x50 [ +0.000008] ____kasan_slab_free+0x128/0x1d4 [ +0.000008] __kasan_slab_free+0x18/0x24 [ +0.000007] slab_free_freelist_hook+0x108/0x230 [ +0.000010] kfree+0x110/0x35c [ +0.000008] release_nodes+0xf0/0x16c [ +0.000008] devres_release_all+0xfc/0x180 [ +0.000008] device_unbind_cleanup+0x24/0x164 [ +0.000008] device_release_driver_internal+0x3e8/0x5b0 [ +0.000010] driver_detach+0xac/0x1b0 [ +0.000008] bus_remove_driver+0x158/0x29c [ +0.000008] driver_unregister+0x70/0xb0 [ +0.000009] platform_driver_unregister+0x20/0x2c [ +0.000007] 0xffff800003722d98 [ +0.000012] __do_sys_delete_module+0x288/0x400 [ +0.000009] __arm64_sys_delete_module+0x5c/0x80 [ +0.000008] invoke_syscall+0x74/0x260 [ +0.000008] el0_svc_common.constprop.0+0xcc/0x260 [ +0.000008] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000008] el0t_64_sync_handler+0x11c/0x150 [ +0.000009] el0t_64_sync+0x18c/0x190 [ +0.000013] Last potentially related work creation: [ +0.000007] kasan_save_stack+0x2c/0x5c [ +0.000007] __kasan_record_aux_stack+0xb8/0xf0 [ +0.000009] kasan_record_aux_stack_noalloc+0x14/0x20 [ +0.000008] insert_work+0x54/0x290 [ +0.000009] __queue_work+0x48c/0xd24 [ +0.000008] queue_work_on+0x90/0x11c [ +0.000008] call_usermodehelper_exec+0x188/0x404 [ +0.000010] kobject_uevent_env+0x5a8/0x794 [ +0.000010] kobject_uevent+0x14/0x20 [ +0.000008] driver_register+0x230/0x3e4 [ +0.000009] __platform_driver_register+0x6c/0x94 [ +0.000007] gxbb_driver_init+0x28/0x34 [ +0.000010] do_one_initcall+0xc4/0x2b0 [ +0.000008] do_initcalls+0x20c/0x24c [ +0.000010] kernel_init_freeable+0x22c/0x278 [ +0.000009] kernel_init+0x3c/0x170 [ +0.000008] ret_from_fork+0x10/0x20 [ +0.000013] The buggy address belongs to the object at ffff000006731600 which belongs to the cache kmalloc-256 of size 256 [ +0.000009] The buggy address is located 136 bytes inside of 256-byte region [ffff000006731600, ffff000006731700) [ +0.000015] The buggy address belongs to the physical page: [ +0.000008] page:fffffc000019cc00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff000006730a00 pfn:0x6730 [ +0.000011] head:fffffc000019cc00 order:2 compound_mapcount:0 compound_pincount:0 [ +0.000008] flags: 0xffff00000010200(slab|head|node=0|zone=0|lastcpupid=0xffff) [ +0.000016] raw: 0ffff00000010200 fffffc00000c3d08 fffffc0000ef2b08 ffff000000002680 [ +0.000009] raw: ffff000006730a00 0000000000150014 00000001ffffffff 0000000000000000 [ +0.000006] page dumped because: kasan: bad access detected [ +0.000011] Memory state around the buggy address: [ +0.000007] ffff000006731580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ +0.000007] ffff000006731600: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000007] >ffff000006731680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000007] ^ [ +0.000006] ffff000006731700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ +0.000007] ffff000006731780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ +0.000006] ================================================================== Fix by adding 'remove' driver callback for meson-drm, and explicitly deleting the aggregate device. Signed-off-by: -
Adrián Larumbe authored
Unloading the driver triggers the following KASAN warning: [ +0.006275] ============================================================= [ +0.000029] BUG: KASAN: use-after-free in __list_del_entry_valid+0xe0/0x1a0 [ +0.000026] Read of size 8 at addr ffff000020c395e0 by task rmmod/2695 [ +0.000019] CPU: 5 PID: 2695 Comm: rmmod Tainted: G C O 5.19.0-rc6-lrmbkasan+ #1 [ +0.000013] Hardware name: Hardkernel ODROID-N2Plus (DT) [ +0.000008] Call trace: [ +0.000007] dump_backtrace+0x1ec/0x280 [ +0.000013] show_stack+0x24/0x80 [ +0.000008] dump_stack_lvl+0x98/0xd4 [ +0.000011] print_address_description.constprop.0+0x80/0x520 [ +0.000011] print_report+0x128/0x260 [ +0.000007] kasan_report+0xb8/0xfc [ +0.000008] __asan_report_load8_noabort+0x3c/0x50 [ +0.000010] __list_del_entry_valid+0xe0/0x1a0 [ +0.000009] drm_atomic_private_obj_fini+0x30/0x200 [drm] [ +0.000172] drm_bridge_detach+0x94/0x260 [drm] [ +0.000145] drm_encoder_cleanup+0xa4/0x290 [drm] [ +0.000144] drm_mode_config_cleanup+0x118/0x740 [drm] [ +0.000143] drm_mode_config_init_release+0x1c/0x2c [drm] [ +0.000144] drm_managed_release+0x170/0x414 [drm] [ +0.000142] drm_dev_put.part.0+0xc0/0x124 [drm] [ +0.000143] drm_dev_put+0x20/0x30 [drm] [ +0.000142] meson_drv_unbind+0x1d8/0x2ac [meson_drm] [ +0.000028] take_down_aggregate_device+0xb0/0x160 [ +0.000016] component_del+0x18c/0x360 [ +0.000009] meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi] [ +0.000015] platform_remove+0x64/0xb0 [ +0.000009] device_remove+0xb8/0x154 [ +0.000009] device_release_driver_internal+0x398/0x5b0 [ +0.000009] driver_detach+0xac/0x1b0 [ +0.000009] bus_remove_driver+0x158/0x29c [ +0.000009] driver_unregister+0x70/0xb0 [ +0.000008] platform_driver_unregister+0x20/0x2c [ +0.000008] meson_dw_hdmi_platform_driver_exit+0x1c/0x30 [meson_dw_hdmi] [ +0.000012] __do_sys_delete_module+0x288/0x400 [ +0.000011] __arm64_sys_delete_module+0x5c/0x80 [ +0.000009] invoke_syscall+0x74/0x260 [ +0.000009] el0_svc_common.constprop.0+0xcc/0x260 [ +0.000009] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000012] el0t_64_sync_handler+0x11c/0x150 [ +0.000008] el0t_64_sync+0x18c/0x190 [ +0.000018] Allocated by task 0: [ +0.000007] (stack is not available) [ +0.000011] Freed by task 2695: [ +0.000008] kasan_save_stack+0x2c/0x5c [ +0.000011] kasan_set_track+0x2c/0x40 [ +0.000008] kasan_set_free_info+0x28/0x50 [ +0.000009] ____kasan_slab_free+0x128/0x1d4 [ +0.000008] __kasan_slab_free+0x18/0x24 [ +0.000007] slab_free_freelist_hook+0x108/0x230 [ +0.000011] kfree+0x110/0x35c [ +0.000008] release_nodes+0xf0/0x16c [ +0.000009] devres_release_group+0x180/0x270 [ +0.000008] component_unbind+0x128/0x1e0 [ +0.000010] component_unbind_all+0x1b8/0x264 [ +0.000009] meson_drv_unbind+0x1a0/0x2ac [meson_drm] [ +0.000025] take_down_aggregate_device+0xb0/0x160 [ +0.000009] component_del+0x18c/0x360 [ +0.000009] meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi] [ +0.000012] platform_remove+0x64/0xb0 [ +0.000008] device_remove+0xb8/0x154 [ +0.000009] device_release_driver_internal+0x398/0x5b0 [ +0.000009] driver_detach+0xac/0x1b0 [ +0.000009] bus_remove_driver+0x158/0x29c [ +0.000008] driver_unregister+0x70/0xb0 [ +0.000008] platform_driver_unregister+0x20/0x2c [ +0.000008] meson_dw_hdmi_platform_driver_exit+0x1c/0x30 [meson_dw_hdmi] [ +0.000011] __do_sys_delete_module+0x288/0x400 [ +0.000010] __arm64_sys_delete_module+0x5c/0x80 [ +0.000008] invoke_syscall+0x74/0x260 [ +0.000008] el0_svc_common.constprop.0+0xcc/0x260 [ +0.000008] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000009] el0t_64_sync_handler+0x11c/0x150 [ +0.000009] el0t_64_sync+0x18c/0x190 [ +0.000014] The buggy address belongs to the object at ffff000020c39000 which belongs to the cache kmalloc-4k of size 4096 [ +0.000008] The buggy address is located 1504 bytes inside of 4096-byte region [ffff000020c39000, ffff000020c3a000) [ +0.000016] The buggy address belongs to the physical page: [ +0.000009] page:fffffc0000830e00 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x20c38 [ +0.000013] head:fffffc0000830e00 order:3 compound_mapcount:0 compound_pincount:0 [ +0.000008] flags: 0xffff00000010200(slab|head|node=0|zone=0|lastcpupid=0xffff) [ +0.000019] raw: 0ffff00000010200 fffffc0000fd4808 fffffc0000126208 ffff000000002e80 [ +0.000009] raw: 0000000000000000 0000000000020002 00000001ffffffff 0000000000000000 [ +0.000008] page dumped because: kasan: bad access detected [ +0.000011] Memory state around the buggy address: [ +0.000008] ffff000020c39480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000007] ffff000020c39500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000007] >ffff000020c39580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000007] ^ [ +0.000007] ffff000020c39600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000007] ffff000020c39680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000006] ================================================================== The reason this is happening is unloading meson-dw-hdmi will cause the component API to take down the aggregate device, which in turn will cause all devres-managed memory to be freed, including the struct dw_hdmi allocated in dw_hdmi_probe. This struct embeds a struct drm_bridge that is added at the end of the function, and which is later on picked up in meson_encoder_hdmi_init. However, when attaching the bridge to the encoder created in meson_encoder_hdmi_init, it's linked to the encoder's bridge chain, from where it never leaves, even after devres_release_group is called when the driver's components are unbound and the embedding structure freed. Then, when calling drm_dev_put in the aggregate driver's unbind function, drm_bridge_detach is called for every single bridge linked to the encoder, including the one whose memory had already been deallocated. Fix by calling component_unbind_all after drm_dev_put. Signed-off-by: -
Francesco Dolcini authored
Add comments on the lt8912_write_lvds_config() config to document the current settings and to make it clear that this is a hardcoded configuration not relevant for the HDMI output (could be removed without affecting the HDMI port). No changes on the actual register writes. Signed-off-by:
Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by:
Philippe Schenker <philippe.schenker@toradex.com> Acked-by:
Adrien Grassein <adrien.grassein@gmail.com> Signed-off-by:
-
- 22 Sep, 2022 1 commit
-
-
Arunpravin Paneer Selvam authored
A user reported that when he starts a game (MTGA) with wine, he observed an error msg failed to pin framebuffer with error -12. Found an issue with the VRAM mem type eviction decision condition logic. This patch will fix the if condition code error. Gitlab bug link: https://gitlab.freedesktop.org/drm/amd/-/issues/2159 Fixes: ded910f3 ("drm/amdgpu: Implement intersect/compatible functions") Signed-off-by:
Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220922151447.265696-1-Arunpravin.PaneerSelvam@amd.comReviewed-by:
-
- 21 Sep, 2022 1 commit
-
-
Rafael Mendonca authored
If the copy of the description string from userspace fails, then the page for the instance descriptor doesn't get freed before returning -EFAULT, which leads to a memleak. Fixes: 7a7a933e ("drm/vmwgfx: Introduce VMware mks-guest-stats") Signed-off-by:
Rafael Mendonca <rafaelmendsr@gmail.com> Reviewed-by:
Martin Krastev <krastevm@vmware.com> Signed-off-by:
Zack Rusin <zackr@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220916204751.720716-1-rafaelmendsr@gmail.com
-
- 20 Sep, 2022 8 commits
-
-
Minghao Chi authored
The implementation of strscpy() is more robust and safer. That's now the recommended way to copy NUL terminated strings. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
Minghao Chi <chi.minghao@zte.com.cn> Reviewed-by:
-
Jammy Huang authored
Some cases are not handled well for ast2600. Signed-off-by:
Jammy Huang <jammy_huang@aspeedtech.com> Signed-off-by:
-
Jammy Huang authored
Add 1152x864 into support list. Signed-off-by:
-
Thomas Zimmermann authored
Provide DRM_PLANE_NON_ATOMIC_FUNCS, which initializes plane functions of non-atomic drivers to default values. The macro is not supposed to be used in new code, but helps with documenting and finding existing users. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Lyude Paul <lyude@redhat.com> # nouveau Link: https://patchwork.freedesktop.org/patch/msgid/20220909105947.6487-5-tzimmermann@suse.de
-
Thomas Zimmermann authored
The plane update and disable helpers are only useful for non-atomic drivers. Print a warning if an atomic driver calls them. Suggested-by:
-
Thomas Zimmermann authored
Provide drm_univeral_plane_alloc() to allocate and initialize a plane. Code for non-atomic drivers uses this pattern. Convert them to the new function. The modeset helpers contain a quirk for handling their color formats differently. Set the flag outside plane allocation. The new function is already deprecated to some extend. Drivers should rather use drmm_univeral_plane_alloc() or drm_universal_plane_init(). v2: * kerneldoc fixes (Javier) * grammar fixes in commit message Signed-off-by:
-
Thomas Zimmermann authored
Open-code drm_plane_init() and remove the function from DRM. The implementation of drm_plane_init() is a simple wrapper around a call to drm_universal_plane_init(), so drivers can just use that instead. Signed-off-by:
Jyri Sarha <jyri.sarha@iki.fi> Link: https://patchwork.freedesktop.org/patch/msgid/20220909105947.6487-2-tzimmermann@suse.de
-
Jiapeng Chong authored
drivers/gpu/drm/drm_atomic_helper.c:802: warning: expecting prototype for drm_atomic_helper_check_wb_connector_state(). Prototype was for drm_atomic_helper_check_wb_encoder_state() instead. Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2216Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by:
-
- 19 Sep, 2022 7 commits
-
-
Christian König authored
That check must now come after grabing the spinlock, not before. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220919120618.113332-1-christian.koenig@amd.com
-
Robert Foss authored
Revert this patch since it depends on devicetree functionality that previously has been reverted in the below commit. commit e798ba33 ("Revert "dt-bindings: Add byteswap order to chrontel ch7033"") This reverts commit ce9564cf. Signed-off-by:
Robert Foss <robert.foss@linaro.org> Reviewed-by:
-
Robert Foss authored
This commit was accidentally reverted instead of another commit, and therefore needs to be reinstated. This reverts commit 8c9c40ec. Fixes: 8c9c40ec ("Revert "drm/bridge: ti-sn65dsi86: Implement bridge connector operations for DP"") Signed-off-by:
-
Yang Yingliang authored
mtk_dp_driver is only used in mtk_dp.c now, change it to static. Fixes: f70ac097 ("drm/mediatek: Add MT8195 Embedded DisplayPort driver") Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
Chun-Kuang Hu <chunkuang.hu@kernel.org> Signed-off-by:
-
Bo-Chen Chen authored
Fix debug message formatting by using %s instead of 0x%x. Fixes: f70ac097 ("drm/mediatek: Add MT8195 Embedded DisplayPort driver") Reported-by:
Bo-Chen Chen <rex-bc.chen@mediatek.com> Reviewed-by:
Matthias Brugger <matthias.bgg@gmail.com> Acked-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by:
-
Bo-Chen Chen authored
Some definitions in mtk_dp_reg.h are not used, so remove these redundant codes. Signed-off-by:
-
Bo-Chen Chen authored
In order to improve human readability, reduce the indentation by returning early if the dp/edp cable is not plugged in. Signed-off-by:
-
- 18 Sep, 2022 5 commits
-
-
Hans de Goede authored
On machines without an Intel video opregion the acpi_video driver immediately probes the ACPI video bus and used to also immediately register acpi_video# backlight devices when supported. Once the drm/kms driver then loaded later and possibly registered a native backlight device then the drivers/acpi/video_detect.c code unregistered the acpi_video0 device to avoid there being 2 backlight devices (when acpi_video_get_backlight_type()==native). This means that userspace used to briefly see 2 devices and the disappearing of acpi_video0 after a brief time confuses the systemd backlight level save/restore code, see e.g.: https://bbs.archlinux.org/viewtopic.php?id=269920 To fix this the ACPI video code has been modified to make backlight class device registration a separate step, relying on the drm/kms driver to ask for the acpi_video backlight registration after it is done setting up its native backlight device. Add a call to the new acpi_video_register_backlight() function after setting up the gma500's native backlight, so that the acpi_video backlight device gets registered on systems where the gma500's native backlight device is not registered. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220917205920.647212-6-hdegoede@redhat.com
-
Hans de Goede authored
Before this commit when we want userspace to use the acpi_video backlight device we register both the GPU's native backlight device and acpi_video's firmware acpi_video# backlight device. This relies on userspace preferring firmware type backlight devices over native ones. Registering 2 backlight devices for a single display really is undesirable, don't register the GPU's native backlight device when another backlight device should be used. Signed-off-by:
-
Hans de Goede authored
Use backlight_get_brightness() instead of directly referencing bd->props.brightness. This will take backlight_is_blank() into account, properly setting brightness to 0 when screen-blanking has been requested through the backlight sysfs interface. Suggested-by:
Sam Ravnborg <sam@ravnborg.org> Acked-by:
-
Hans de Goede authored
Change the type for the registered backlight class device from platform to raw/native. The poulsbo/cedarview/oaktrail backlight support is using native GPU backlight control and as such the type should be raw (aka native) as is done by all the other native GPU backlight driver code. Note this will not change much from userspace's point of view. poulsbo/cedarview laptops typically offer both an ACPI-video backlight interface as well as the native GPU backlight interface. The /sys/class/backlight/acpi_video0 has a type of firmware and userspace typically looks for firmware devices before looking for platform devices. The typical standard lookup order is: firmware -> platform -> raw This means that both before and after this change typical userspace backlight consumers (sich as e.g. GNOME) will prefer the firmware acpi_video0 backlight device. This has been tested on a Packard Bell Dot SC (Intel Atom N2600, cedarview) and a Sony Vaio vpc-x11s1e (Intel N540, poulsbo) laptop. Signed-off-by:
-
Hans de Goede authored
Refactor backlight support so that the gma_backlight_enable() / gma_backlight_disable() / gma_backlight_set() functions used by the Opregion handle will also work if no backlight_device gets registered. This is a preparation patch for not registering the gma500's own backlight device when acpi_video should be used, since registering 2 backlight devices for a single display really is undesirable. Since the acpi-video interface often uses the OpRegion we need to keep the OpRegion functional even when dev_priv->backlight_device is NULL. As a result of this refactor the actual backlight_device_register() call is moved to the shared backlight.c code and all #ifdefs related to CONFIG_BACKLIGHT_CLASS_DEVICE are now also limited to backlight.c . No functional changes intended. This has been tested on a Packard Bell Dot SC (Intel Atom N2600, cedarview) and a Sony Vaio vpc-x11s1e (Intel N540, poulsbo) laptop. Changes in v2: - Fix unused variable warnings when CONFIG_BACKLIGHT is not selected by marking the 2 variables as __maybe_unused. Signed-off-by:
-
- 17 Sep, 2022 3 commits
-
-
Maya Matuszczyk authored
Yet another x86 gaming handheld. This one has many SKUs with quite a few of DMI strings, so let's just use a catchall, just as with Aya Neo Next. Signed-off-by:
Maya Matuszczyk <maccraft123mc@gmail.com> Signed-off-by:
-
Hans de Goede authored
The psb_runtime_suspend/resume/thaw/freeze/restore functions are all just 1:1 wrappers around gma_power_suspend/_resume. Drop these wrappers and use the DEFINE_RUNTIME_DEV_PM_OPS() macro to define the dev_pm_ops struct. Signed-off-by:
-
Hans de Goede authored
Rewrite the power.c code. For some reason this was doing locking + refcounting + state (suspended or not) bookkeeping all by itself. But there is no reason for this, this is all taken care of by the runtime-pm core, through pm_runtime_get()/_put(). Besides this not being necessary the DIY code is also quite weird/ buggy in some places. E.g. power_begin() would manually do a resume when not resumed already and force_on=true, followed by a pm_runtime_get(), which will cause a call to gma_power_resume() to get scheduled which would redo the entire resume again. Which can all be replaced by a single pm_runtime_get_sync() call. Note that this is just a cleanup, this does not actually fix the (disabled through #if 0) runtime-pm support. It does now call pm_runtime_enable(), but only after doing a pm_runtime_get() at probe-time, so the device is never runtime suspended. Doing this permanent get() + enable() instead of not calling enable() at all is necessary for the pm_runtime_get_if_in_use() call in gma_power_begin() to work properly. Note this also removes the gma_power_is_on() call a check like this without actually holding a reference is always racy, so it is a bad idea (and therefor has no pm_runtime_foo() equivalent). The 2 code paths which were using gma_power_is_on() are actually both guaranteed to only run when the device is powered-on so the 2 checks can simply be dropped. Signed-off-by:
-
