Skip to content
Snippets Groups Projects
  1. Feb 06, 2025
  2. Feb 04, 2025
  3. Feb 03, 2025
  4. Jan 31, 2025
    • Hans Verkuil's avatar
      gpu: drm_dp_cec: fix broken CEC adapter properties check · 6daaae5f
      Hans Verkuil authored and Dmitry Baryshkov's avatar Dmitry Baryshkov committed
      
      If the hotplug detect of a display is low for longer than one second
      (configurable through drm_dp_cec_unregister_delay), then the CEC adapter
      is unregistered since we assume the display was disconnected. If the
      HPD went low for less than one second, then we check if the properties
      of the CEC adapter have changed, since that indicates that we actually
      switch to new hardware and we have to unregister the old CEC device and
      register a new one.
      
      Unfortunately, the test for changed properties was written poorly, and
      after a new CEC capability was added to the CEC core code the test always
      returned true (i.e. the properties had changed).
      
      As a result the CEC device was unregistered and re-registered for every
      HPD toggle. If the CEC remote controller integration was also enabled
      (CONFIG_MEDIA_CEC_RC was set), then the corresponding input device was
      also unregistered and re-registered. As a result the input device in
      /sys would keep incrementing its number, e.g.:
      
      /sys/devices/pci0000:00/0000:00:08.1/0000:e7:00.0/rc/rc0/input20
      
      Since short HPD toggles are common, the number could over time get into
      the thousands.
      
      While not a serious issue (i.e. nothing crashes), it is not intended
      to work that way.
      
      This patch changes the test so that it only checks for the single CEC
      capability that can actually change, and it ignores any other
      capabilities, so this is now safe as well if new caps are added in
      the future.
      
      With the changed test the bit under #ifndef CONFIG_MEDIA_CEC_RC can be
      dropped as well, so that's a nice cleanup.
      
      Signed-off-by: default avatarHans Verkuil <hverkuil@xs4all.nl>
      Reported-by: default avatarFarblos <farblos@vodafonemail.de>
      Reviewed-by: default avatarDmitry Baryshkov <dmitry.baryshkov@linaro.org>
      Fixes: 2c6d1fff ("drm: add support for DisplayPort CEC-Tunneling-over-AUX")
      Tested-by: default avatarFarblos <farblos@vodafonemail.de>
      Link: https://patchwork.freedesktop.org/patch/msgid/361bb03d-1691-4e23-84da-0861ead5dbdc@xs4all.nl
      
      
      Signed-off-by: default avatarDmitry Baryshkov <dmitry.baryshkov@linaro.org>
      6daaae5f
  5. Jan 29, 2025
  6. Jan 28, 2025
    • Thomas Zimmermann's avatar
      drm/ast: astdp: Fix timeout for enabling video signal · fd39c41b
      Thomas Zimmermann authored
      
      The ASTDP transmitter sometimes takes up to 1 second for enabling the
      video signal, while the timeout is only 200 msec. This results in a
      kernel error message. Increase the timeout to 1 second. An example
      of the error message is shown below.
      
      [  697.084433] ------------[ cut here ]------------
      [  697.091115] ast 0000:02:00.0: [drm] drm_WARN_ON(!__ast_dp_wait_enable(ast, enabled))
      [  697.091233] WARNING: CPU: 1 PID: 160 at drivers/gpu/drm/ast/ast_dp.c:232 ast_dp_set_enable+0x123/0x140 [ast]
      [...]
      [  697.272469] RIP: 0010:ast_dp_set_enable+0x123/0x140 [ast]
      [...]
      [  697.415283] Call Trace:
      [  697.420727]  <TASK>
      [  697.425908]  ? show_trace_log_lvl+0x196/0x2c0
      [  697.433304]  ? show_trace_log_lvl+0x196/0x2c0
      [  697.440693]  ? drm_atomic_helper_commit_modeset_enables+0x30a/0x470
      [  697.450115]  ? ast_dp_set_enable+0x123/0x140 [ast]
      [  697.458059]  ? __warn.cold+0xaf/0xca
      [  697.464713]  ? ast_dp_set_enable+0x123/0x140 [ast]
      [  697.472633]  ? report_bug+0x134/0x1d0
      [  697.479544]  ? handle_bug+0x58/0x90
      [  697.486127]  ? exc_invalid_op+0x13/0x40
      [  697.492975]  ? asm_exc_invalid_op+0x16/0x20
      [  697.500224]  ? preempt_count_sub+0x14/0xc0
      [  697.507473]  ? ast_dp_set_enable+0x123/0x140 [ast]
      [  697.515377]  ? ast_dp_set_enable+0x123/0x140 [ast]
      [  697.523227]  drm_atomic_helper_commit_modeset_enables+0x30a/0x470
      [  697.532388]  drm_atomic_helper_commit_tail+0x58/0x90
      [  697.540400]  ast_mode_config_helper_atomic_commit_tail+0x30/0x40 [ast]
      [  697.550009]  commit_tail+0xfe/0x1d0
      [  697.556547]  drm_atomic_helper_commit+0x198/0x1c0
      
      This is a cosmetical problem. Enabling the video signal still works
      even with the error message. The problem has always been present, but
      only recent versions of the ast driver warn about missing the timeout.
      
      Signed-off-by: default avatarThomas Zimmermann <tzimmermann@suse.de>
      Fixes: 4e29cc7c ("drm/ast: astdp: Replace ast_dp_set_on_off()")
      Cc: Thomas Zimmermann <tzimmermann@suse.de>
      Cc: Jocelyn Falempe <jfalempe@redhat.com>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: dri-devel@lists.freedesktop.org
      Cc: <stable@vger.kernel.org> # v6.13+
      Reviewed-by: default avatarJocelyn Falempe <jfalempe@redhat.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20250127134423.84266-1-tzimmermann@suse.de
      fd39c41b
  7. Jan 25, 2025
  8. Jan 24, 2025
  9. Jan 23, 2025
    • Maíra Canal's avatar
      drm/v3d: Assign job pointer to NULL before signaling the fence · 6e64d6b3
      Maíra Canal authored
      
      In commit e4b5ccd3 ("drm/v3d: Ensure job pointer is set to NULL
      after job completion"), we introduced a change to assign the job pointer
      to NULL after completing a job, indicating job completion.
      
      However, this approach created a race condition between the DRM
      scheduler workqueue and the IRQ execution thread. As soon as the fence is
      signaled in the IRQ execution thread, a new job starts to be executed.
      This results in a race condition where the IRQ execution thread sets the
      job pointer to NULL simultaneously as the `run_job()` function assigns
      a new job to the pointer.
      
      This race condition can lead to a NULL pointer dereference if the IRQ
      execution thread sets the job pointer to NULL after `run_job()` assigns
      it to the new job. When the new job completes and the GPU emits an
      interrupt, `v3d_irq()` is triggered, potentially causing a crash.
      
      [  466.310099] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000c0
      [  466.318928] Mem abort info:
      [  466.321723]   ESR = 0x0000000096000005
      [  466.325479]   EC = 0x25: DABT (current EL), IL = 32 bits
      [  466.330807]   SET = 0, FnV = 0
      [  466.333864]   EA = 0, S1PTW = 0
      [  466.337010]   FSC = 0x05: level 1 translation fault
      [  466.341900] Data abort info:
      [  466.344783]   ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
      [  466.350285]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
      [  466.355350]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
      [  466.360677] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000089772000
      [  466.367140] [00000000000000c0] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
      [  466.375875] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
      [  466.382163] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device algif_hash algif_skcipher af_alg bnep binfmt_misc vc4 snd_soc_hdmi_codec drm_display_helper cec brcmfmac_wcc spidev rpivid_hevc(C) drm_client_lib brcmfmac hci_uart drm_dma_helper pisp_be btbcm brcmutil snd_soc_core aes_ce_blk v4l2_mem2mem bluetooth aes_ce_cipher snd_compress videobuf2_dma_contig ghash_ce cfg80211 gf128mul snd_pcm_dmaengine videobuf2_memops ecdh_generic sha2_ce ecc videobuf2_v4l2 snd_pcm v3d sha256_arm64 rfkill videodev snd_timer sha1_ce libaes gpu_sched snd videobuf2_common sha1_generic drm_shmem_helper mc rp1_pio drm_kms_helper raspberrypi_hwmon spi_bcm2835 gpio_keys i2c_brcmstb rp1 raspberrypi_gpiomem rp1_mailbox rp1_adc nvmem_rmem uio_pdrv_genirq uio i2c_dev drm ledtrig_pattern drm_panel_orientation_quirks backlight fuse dm_mod ip_tables x_tables ipv6
      [  466.458429] CPU: 0 UID: 1000 PID: 2008 Comm: chromium Tainted: G         C         6.13.0-v8+ #18
      [  466.467336] Tainted: [C]=CRAP
      [  466.470306] Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT)
      [  466.476157] pstate: 404000c9 (nZcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
      [  466.483143] pc : v3d_irq+0x118/0x2e0 [v3d]
      [  466.487258] lr : __handle_irq_event_percpu+0x60/0x228
      [  466.492327] sp : ffffffc080003ea0
      [  466.495646] x29: ffffffc080003ea0 x28: ffffff80c0c94200 x27: 0000000000000000
      [  466.502807] x26: ffffffd08dd81d7b x25: ffffff80c0c94200 x24: ffffff8003bdc200
      [  466.509969] x23: 0000000000000001 x22: 00000000000000a7 x21: 0000000000000000
      [  466.517130] x20: ffffff8041bb0000 x19: 0000000000000001 x18: 0000000000000000
      [  466.524291] x17: ffffffafadfb0000 x16: ffffffc080000000 x15: 0000000000000000
      [  466.531452] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
      [  466.538613] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffffd08c527eb0
      [  466.545777] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
      [  466.552941] x5 : ffffffd08c4100d0 x4 : ffffffafadfb0000 x3 : ffffffc080003f70
      [  466.560102] x2 : ffffffc0829e8058 x1 : 0000000000000001 x0 : 0000000000000000
      [  466.567263] Call trace:
      [  466.569711]  v3d_irq+0x118/0x2e0 [v3d] (P)
      [  466.573826]  __handle_irq_event_percpu+0x60/0x228
      [  466.578546]  handle_irq_event+0x54/0xb8
      [  466.582391]  handle_fasteoi_irq+0xac/0x240
      [  466.586498]  generic_handle_domain_irq+0x34/0x58
      [  466.591128]  gic_handle_irq+0x48/0xd8
      [  466.594798]  call_on_irq_stack+0x24/0x58
      [  466.598730]  do_interrupt_handler+0x88/0x98
      [  466.602923]  el0_interrupt+0x44/0xc0
      [  466.606508]  __el0_irq_handler_common+0x18/0x28
      [  466.611050]  el0t_64_irq_handler+0x10/0x20
      [  466.615156]  el0t_64_irq+0x198/0x1a0
      [  466.618740] Code: 52800035 3607faf3 f9442e80 52800021 (f9406018)
      [  466.624853] ---[ end trace 0000000000000000 ]---
      [  466.629483] Kernel panic - not syncing: Oops: Fatal exception in interrupt
      [  466.636384] SMP: stopping secondary CPUs
      [  466.640320] Kernel Offset: 0x100c400000 from 0xffffffc080000000
      [  466.646259] PHYS_OFFSET: 0x0
      [  466.649141] CPU features: 0x100,00000170,00901250,0200720b
      [  466.654644] Memory Limit: none
      [  466.657706] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---
      
      Fix the crash by assigning the job pointer to NULL before signaling the
      fence. This ensures that the job pointer is cleared before any new job
      starts execution, preventing the race condition and the NULL pointer
      dereference crash.
      
      Cc: stable@vger.kernel.org
      Fixes: e4b5ccd3 ("drm/v3d: Ensure job pointer is set to NULL after job completion")
      Signed-off-by: default avatarMaíra Canal <mcanal@igalia.com>
      Reviewed-by: default avatarJose Maria Casanova Crespo <jmcasanova@igalia.com>
      Reviewed-by: default avatarIago Toral Quiroga <itoral@igalia.com>
      Tested-by: default avatarPhil Elwell <phil@raspberrypi.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20250123012403.20447-1-mcanal@igalia.com
    • Maarten Lankhorst's avatar
      Merge remote-tracking branch 'drm/drm-next' into drm-misc-next-fixes · 37ba6c7f
      Maarten Lankhorst authored
      
      A regression was caused by commit e4b5ccd3 ("drm/v3d: Ensure job pointer is set to NULL
      after job completion"), but this commit is not yet in next-fixes,
      fast-forward it.
      
      Try #2, first one didn't have v6.13 in it.
      
      Signed-off-by: default avatarMaarten Lankhorst <dev@lankhorst.se>
      37ba6c7f
    • Simona Vetter's avatar
      Merge v6.13 into drm-next · 07c5b277
      Simona Vetter authored
      A regression was caused by commit e4b5ccd3 ("drm/v3d: Ensure job
      pointer is set to NULL after job completion"), but this commit is not
      yet in next-fixes, fast-forward it.
      
      Note that this recreates Linus merge in 96c84703 ("Merge tag
      'drm-next-2025-01-17' of https://gitlab.freedesktop.org/drm/kernel"
      
      )
      because I didn't want to backmerge a random point in the merge window.
      
      Signed-off-by: default avatarSimona Vetter <simona.vetter@ffwll.ch>
      07c5b277
    • Thomas Zimmermann's avatar
      drm/bochs: Do not put DRM device in PCI remove callback · 5247a8b3
      Thomas Zimmermann authored
      
      Removing the bochs PCI device should mark the DRM device as unplugged
      without removing it. Hence clear the respective call to drm_dev_put()
      from bochs_pci_remove().
      
      Fixes a double unref in devm_drm_dev_init_release(). An example error
      message is shown below:
      
      [   32.958338] BUG: KASAN: use-after-free in drm_dev_put.part.0+0x1b/0x90
      [   32.958850] Write of size 4 at addr ffff888152134004 by task (udev-worker)/591
      [   32.959574] CPU: 3 UID: 0 PID: 591 Comm: (udev-worker) Tainted: G            E      6.13.0-rc2-1-default+ #3417
      [   32.960316] Tainted: [E]=UNSIGNED_MODULE
      [   32.960637] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014
      [   32.961429] Call Trace:
      [   32.961433]  <TASK>
      [   32.961439]  dump_stack_lvl+0x68/0x90
      [   32.961452]  print_address_description.constprop.0+0x88/0x330
      [   32.961461]  ? preempt_count_sub+0x14/0xc0
      [   32.961473]  print_report+0xe2/0x1d0
      [   32.961479]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   32.963725]  ? __virt_addr_valid+0x143/0x320
      [   32.964077]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   32.964463]  ? drm_dev_put.part.0+0x1b/0x90
      [   32.964817]  kasan_report+0xce/0x1a0
      [   32.965123]  ? drm_dev_put.part.0+0x1b/0x90
      [   32.965474]  kasan_check_range+0xff/0x1c0
      [   32.965806]  drm_dev_put.part.0+0x1b/0x90
      [   32.966138]  release_nodes+0x84/0xc0
      [   32.966447]  devres_release_all+0xd2/0x110
      [   32.966788]  ? __pfx_devres_release_all+0x10/0x10
      [   32.967177]  ? preempt_count_sub+0x14/0xc0
      [   32.967523]  device_unbind_cleanup+0x16/0xc0
      [   32.967886]  really_probe+0x1b7/0x570
      [   32.968207]  __driver_probe_device+0xca/0x1b0
      [   32.968568]  driver_probe_device+0x4a/0xf0
      [   32.968907]  __driver_attach+0x10b/0x290
      [   32.969239]  ? __pfx___driver_attach+0x10/0x10
      [   32.969598]  bus_for_each_dev+0xc0/0x110
      [   32.969923]  ? __pfx_bus_for_each_dev+0x10/0x10
      [   32.970291]  ? bus_add_driver+0x17a/0x2b0
      [   32.970622]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   32.971011]  bus_add_driver+0x19a/0x2b0
      [   32.971335]  driver_register+0xd8/0x160
      [   32.971671]  ? __pfx_bochs_pci_driver_init+0x10/0x10 [bochs]
      [   32.972130]  do_one_initcall+0xba/0x390
      [...]
      
      After unplugging the DRM device, clients will close their references.
      Closing the final reference will also release the DRM device.
      
      Reported-by: default avatarDr. David Alan Gilbert <dave@treblig.org>
      Closes: https://lore.kernel.org/lkml/Z18dbfDAiFadsSdg@gallifrey/
      
      
      Fixes: 04826f58 ("drm/bochs: Allocate DRM device in struct bochs_device")
      Cc: Thomas Zimmermann <tzimmermann@suse.de>
      Cc: Gerd Hoffmann <kraxel@redhat.com>
      Cc: virtualization@lists.linux.dev
      Signed-off-by: default avatarThomas Zimmermann <tzimmermann@suse.de>
      Reviewed-by: default avatarDmitry Baryshkov <dmitry.baryshkov@linaro.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20250103095615.231162-1-tzimmermann@suse.de
      5247a8b3
  10. Jan 22, 2025
  11. Jan 21, 2025
  12. Jan 19, 2025
  13. Jan 18, 2025
    • Linus Torvalds's avatar
      Merge tag 'trace-v6.13-rc7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace · fda5e3f2
      Linus Torvalds authored
      Pull tracing fix from Steven Rostedt:
       "Fix regression in GFP output in trace events
      
        It was reported that the GFP flags in trace events went from human
        readable to just their hex values:
      
            gfp_flags=GFP_HIGHUSER_MOVABLE|__GFP_COMP to gfp_flags=0x140cca
      
        This was caused by a change that added the use of enums in calculating
        the GFP flags.
      
        As defines get translated into their values in the trace event format
        files, the user space tooling could easily convert the GFP flags into
        their symbols via the __print_flags() helper macro.
      
        The problem is that enums do not get converted, and the names of the
        enums show up in the format files and user space tooling cannot
        translate them.
      
        Add TRACE_DEFINE_ENUM() around the enums used for GFP flags which is
        the tracing infrastructure macro that informs the tracing subsystem
        what the values for enums and it can then expose that to user space"
      
      * tag 'trace-v6.13-rc7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
        tracing: gfp: Fix the GFP enum values shown for user space tracing tools
      fda5e3f2
  14. Jan 17, 2025
Loading