May 2025 - Linux-stable-mirror

Re: [PATCH v4 00/24] Add support for HEVC and VP9 codecs in decoder

by Dikshita Agarwal

Hi All, Pls ignore this, b4 messed up. Will post a proper series soon. Thanks, Dikshita On 5/7/2025 12:10 PM, Dikshita Agarwal wrote: > Hi All, > > This patch series adds initial support for the HEVC(H.265) and VP9 > codecs in iris decoder. The objective of this work is to extend the > decoder's capabilities to handle HEVC and VP9 codec streams, > including necessary format handling and buffer management. > In addition, the series also includes a set of fixes to address issues > identified during testing of these additional codecs. > > These patches also address the comments and feedback received from the > RFC patches previously sent. I have made the necessary improvements > based on the community's suggestions. > > Changes in v4: > - Splitted patch patch 06/23 in two patches (Bryan) > - Simplified the conditional logic in patch 13/23 (Bryan) > - Fix the value of H265_NUM_TILE_ROW macro (Neil) > - Link to v3: https://lore.kernel.org/r/20250502-qcom-iris-hevc-vp9-v3-0-552158a10a7d@qui… > > Changes in v3: > - Introduced two wrappers with explicit names to handle destroy internal > buffers (Nicolas) > - Used sub state check instead of introducing new boolean (Vikash) > - Addressed other comments (Vikash) > - Reorderd patches to have all fixes patches first (Dmitry) > - Link to v2: > https://lore.kernel.org/r/20250428-qcom-iris-hevc-vp9-v2-0-3a6013ecb8a5@qui… > > Changes in v2: > - Added Changes to make sure all buffers are released in session close > (bryna) > - Added tracking for flush responses to fix a timing issue. > - Added a handling to fix timing issue in reconfig > - Splitted patch 06/20 in two patches (Bryan) > - Added missing fixes tag (bryan) > - Updated fluster report (Nicolas) > - Link to v1: > https://lore.kernel.org/r/20250408-iris-dec-hevc-vp9-v1-0-acd258778bd6@quic… > > Changes sinces RFC: > - Added additional fixes to address issues identified during further > testing. > - Moved typo fix to a seperate patch [Neil] > - Reordered the patches for better logical flow and clarity [Neil, > Dmitry] > - Added fixes tag wherever applicable [Neil, Dmitry] > - Removed the default case in the switch statement for codecs [Bryan] > - Replaced if-else statements with switch-case [Bryan] > - Added comments for mbpf [Bryan] > - RFC: > https://lore.kernel.org/linux-media/20250305104335.3629945-1-quic_dikshita@… > > This patch series depends on [1] & [2] > [1] > https://lore.kernel.org/linux-media/20250417-topic-sm8x50-iris-v10-v7-0-f02… > [2] > https://lore.kernel.org/linux-media/20250424-qcs8300_iris-v5-0-f118f505c300… > > These patches are tested on SM8250 and SM8550 with v4l2-ctl and > Gstreamer for HEVC and VP9 decoders, at the same time ensured that > the existing H264 decoder functionality remains uneffected. > > Note: 1 of the fluster compliance test is fixed with firmware [3] > [3]: > https://lore.kernel.org/linux-firmware/1a511921-446d-cdc4-0203-084c88a5dc1e… > > The result of fluster test on SM8550: > 131/147 testcases passed while testing JCT-VC-HEVC_V1 with > GStreamer-H.265-V4L2-Gst1.0. > The failing test case: > - 10 testcases failed due to unsupported 10 bit format. > - DBLK_A_MAIN10_VIXS_4 > - INITQP_B_Main10_Sony_1 > - TSUNEQBD_A_MAIN10_Technicolor_2 > - WP_A_MAIN10_Toshiba_3 > - WP_MAIN10_B_Toshiba_3 > - WPP_A_ericsson_MAIN10_2 > - WPP_B_ericsson_MAIN10_2 > - WPP_C_ericsson_MAIN10_2 > - WPP_E_ericsson_MAIN10_2 > - WPP_F_ericsson_MAIN10_2 > - 4 testcase failed due to unsupported resolution > - PICSIZE_A_Bossen_1 > - PICSIZE_B_Bossen_1 > - WPP_D_ericsson_MAIN10_2 > - WPP_D_ericsson_MAIN_2 > - 2 testcase failed due to CRC mismatch > - RAP_A_docomo_6 > - RAP_B_Bossen_2 > - BUG reported: > https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/4392 > Analysis - First few frames in this discarded by firmware and are > sent to driver with 0 filled length. Driver send such buffers to > client with timestamp 0 and payload set to 0 and > make buf state to VB2_BUF_STATE_ERROR. Such buffers should be > dropped by GST. But instead, the first frame displayed as green > frame and when a valid buffer is sent to client later with same 0 > timestamp, its dropped, leading to CRC mismatch for first frame. > > 235/305 testcases passed while testing VP9-TEST-VECTORS with > GStreamer-VP9-V4L2-Gst1.0. > The failing test case: > - 64 testcases failed due to unsupported resolution > - vp90-2-02-size-08x08.webm > - vp90-2-02-size-08x10.webm > - vp90-2-02-size-08x16.webm > - vp90-2-02-size-08x18.webm > - vp90-2-02-size-08x32.webm > - vp90-2-02-size-08x34.webm > - vp90-2-02-size-08x64.webm > - vp90-2-02-size-08x66.webm > - vp90-2-02-size-10x08.webm > - vp90-2-02-size-10x10.webm > - vp90-2-02-size-10x16.webm > - vp90-2-02-size-10x18.webm > - vp90-2-02-size-10x32.webm > - vp90-2-02-size-10x34.webm > - vp90-2-02-size-10x64.webm > - vp90-2-02-size-10x66.webm > - vp90-2-02-size-16x08.webm > - vp90-2-02-size-16x10.webm > - vp90-2-02-size-16x16.webm > - vp90-2-02-size-16x18.webm > - vp90-2-02-size-16x32.webm > - vp90-2-02-size-16x34.webm > - vp90-2-02-size-16x64.webm > - vp90-2-02-size-16x66.webm > - vp90-2-02-size-18x08.webm > - vp90-2-02-size-18x10.webm > - vp90-2-02-size-18x16.webm > - vp90-2-02-size-18x18.webm > - vp90-2-02-size-18x32.webm > - vp90-2-02-size-18x34.webm > - vp90-2-02-size-18x64.webm > - vp90-2-02-size-18x66.webm > - vp90-2-02-size-32x08.webm > - vp90-2-02-size-32x10.webm > - vp90-2-02-size-32x16.webm > - vp90-2-02-size-32x18.webm > - vp90-2-02-size-32x32.webm > - vp90-2-02-size-32x34.webm > - vp90-2-02-size-32x64.webm > - vp90-2-02-size-32x66.webm > - vp90-2-02-size-34x08.webm > - vp90-2-02-size-34x10.webm > - vp90-2-02-size-34x16.webm > - vp90-2-02-size-34x18.webm > - vp90-2-02-size-34x32.webm > - vp90-2-02-size-34x34.webm > - vp90-2-02-size-34x64.webm > - vp90-2-02-size-34x66.webm > - vp90-2-02-size-64x08.webm > - vp90-2-02-size-64x10.webm > - vp90-2-02-size-64x16.webm > - vp90-2-02-size-64x18.webm > - vp90-2-02-size-64x32.webm > - vp90-2-02-size-64x34.webm > - vp90-2-02-size-64x64.webm > - vp90-2-02-size-64x66.webm > - vp90-2-02-size-66x08.webm > - vp90-2-02-size-66x10.webm > - vp90-2-02-size-66x16.webm > - vp90-2-02-size-66x18.webm > - vp90-2-02-size-66x32.webm > - vp90-2-02-size-66x34.webm > - vp90-2-02-size-66x64.webm > - vp90-2-02-size-66x66.webm > - 2 testcases failed due to unsupported format > - vp91-2-04-yuv422.webm > - vp91-2-04-yuv444.webm > - 1 testcase failed with CRC mismatch > - vp90-2-22-svc_1280x720_3.ivf > - Bug reported: > https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/4371 > - 2 testcase failed due to unsupported resolution after sequence change > - vp90-2-21-resize_inter_320x180_5_1-2.webm > - vp90-2-21-resize_inter_320x180_7_1-2.webm > - 1 testcase failed due to unsupported stream > - vp90-2-16-intra-only.webm > > The result of fluster test on SM8250: > 133/147 testcases passed while testing JCT-VC-HEVC_V1 with > GStreamer-H.265-V4L2-Gst1.0. > The failing test case: > - 10 testcases failed due to unsupported 10 bit format. > - DBLK_A_MAIN10_VIXS_4 > - INITQP_B_Main10_Sony_1 > - TSUNEQBD_A_MAIN10_Technicolor_2 > - WP_A_MAIN10_Toshiba_3 > - WP_MAIN10_B_Toshiba_3 > - WPP_A_ericsson_MAIN10_2 > - WPP_B_ericsson_MAIN10_2 > - WPP_C_ericsson_MAIN10_2 > - WPP_E_ericsson_MAIN10_2 > - WPP_F_ericsson_MAIN10_2 > - 4 testcase failed due to unsupported resolution > - PICSIZE_A_Bossen_1 > - PICSIZE_B_Bossen_1 > - WPP_D_ericsson_MAIN10_2 > - WPP_D_ericsson_MAIN_2 > > 232/305 testcases passed while testing VP9-TEST-VECTORS with > GStreamer-VP9-V4L2-Gst1.0. > The failing test case: > - 64 testcases failed due to unsupported resolution > - vp90-2-02-size-08x08.webm > - vp90-2-02-size-08x10.webm > - vp90-2-02-size-08x16.webm > - vp90-2-02-size-08x18.webm > - vp90-2-02-size-08x32.webm > - vp90-2-02-size-08x34.webm > - vp90-2-02-size-08x64.webm > - vp90-2-02-size-08x66.webm > - vp90-2-02-size-10x08.webm > - vp90-2-02-size-10x10.webm > - vp90-2-02-size-10x16.webm > - vp90-2-02-size-10x18.webm > - vp90-2-02-size-10x32.webm > - vp90-2-02-size-10x34.webm > - vp90-2-02-size-10x64.webm > - vp90-2-02-size-10x66.webm > - vp90-2-02-size-16x08.webm > - vp90-2-02-size-16x10.webm > - vp90-2-02-size-16x16.webm > - vp90-2-02-size-16x18.webm > - vp90-2-02-size-16x32.webm > - vp90-2-02-size-16x34.webm > - vp90-2-02-size-16x64.webm > - vp90-2-02-size-16x66.webm > - vp90-2-02-size-18x08.webm > - vp90-2-02-size-18x10.webm > - vp90-2-02-size-18x16.webm > - vp90-2-02-size-18x18.webm > - vp90-2-02-size-18x32.webm > - vp90-2-02-size-18x34.webm > - vp90-2-02-size-18x64.webm > - vp90-2-02-size-18x66.webm > - vp90-2-02-size-32x08.webm > - vp90-2-02-size-32x10.webm > - vp90-2-02-size-32x16.webm > - vp90-2-02-size-32x18.webm > - vp90-2-02-size-32x32.webm > - vp90-2-02-size-32x34.webm > - vp90-2-02-size-32x64.webm > - vp90-2-02-size-32x66.webm > - vp90-2-02-size-34x08.webm > - vp90-2-02-size-34x10.webm > - vp90-2-02-size-34x16.webm > - vp90-2-02-size-34x18.webm > - vp90-2-02-size-34x32.webm > - vp90-2-02-size-34x34.webm > - vp90-2-02-size-34x64.webm > - vp90-2-02-size-34x66.webm > - vp90-2-02-size-64x08.webm > - vp90-2-02-size-64x10.webm > - vp90-2-02-size-64x16.webm > - vp90-2-02-size-64x18.webm > - vp90-2-02-size-64x32.webm > - vp90-2-02-size-64x34.webm > - vp90-2-02-size-64x64.webm > - vp90-2-02-size-64x66.webm > - vp90-2-02-size-66x08.webm > - vp90-2-02-size-66x10.webm > - vp90-2-02-size-66x16.webm > - vp90-2-02-size-66x18.webm > - vp90-2-02-size-66x32.webm > - vp90-2-02-size-66x34.webm > - vp90-2-02-size-66x64.webm > - vp90-2-02-size-66x66.webm > - 2 testcases failed due to unsupported format > - vp91-2-04-yuv422.webm > - vp91-2-04-yuv444.webm > - 1 testcase failed with CRC mismatch > - vp90-2-22-svc_1280x720_3.ivf > - Bug raised: > https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/4371 > - 5 testcase failed due to unsupported resolution after sequence change > - vp90-2-21-resize_inter_320x180_5_1-2.webm > - vp90-2-21-resize_inter_320x180_7_1-2.webm > - vp90-2-21-resize_inter_320x240_5_1-2.webm > - vp90-2-21-resize_inter_320x240_7_1-2.webm > - vp90-2-18-resize.ivf > - 1 testcase failed with CRC mismatch > - vp90-2-16-intra-only.webm > Analysis: First few frames are marked by firmware as NO_SHOW frame. > Driver make buf state to VB2_BUF_STATE_ERROR for such frames. > Such buffers should be dropped by GST. But instead, the first frame > is being displayed and when a valid buffer is sent to client later > with same timestamp, its dropped, leading to CRC mismatch for first > frame. > > Signed-off-by: Dikshita Agarwal <dikshita(a)qti.qualcomm.com> > --- > Dikshita Agarwal (24): > media: iris: Skip destroying internal buffer if not dequeued > media: iris: Update CAPTURE format info based on OUTPUT format > media: iris: Avoid updating frame size to firmware during reconfig > media: iris: Drop port check for session property response > media: iris: Prevent HFI queue writes when core is in deinit state > media: iris: Remove error check for non-zero v4l2 controls > media: iris: Remove deprecated property setting to firmware > media: iris: Fix missing function pointer initialization > media: iris: Fix NULL pointer dereference > media: iris: Fix typo in depth variable > media: iris: Track flush responses to prevent premature completion > media: iris: Fix buffer preparation failure during resolution change > media: iris: Send V4L2_BUF_FLAG_ERROR for capture buffers with 0 filled length > media: iris: Skip flush on first sequence change > media: iris: Add handling for corrupt and drop frames > media: iris: Add handling for no show frames > media: iris: Improve last flag handling > media: iris: Remove redundant buffer count check in stream off > media: iris: Add a comment to explain usage of MBPS > media: iris: Add HEVC and VP9 formats for decoder > media: iris: Add platform capabilities for HEVC and VP9 decoders > media: iris: Set mandatory properties for HEVC and VP9 decoders. > media: iris: Add internal buffer calculation for HEVC and VP9 decoders > media: iris: Add codec specific check for VP9 decoder drain handling > > drivers/media/platform/qcom/iris/iris_buffer.c | 35 +- > drivers/media/platform/qcom/iris/iris_buffer.h | 3 +- > drivers/media/platform/qcom/iris/iris_ctrls.c | 35 +- > drivers/media/platform/qcom/iris/iris_hfi_common.h | 1 + > .../platform/qcom/iris/iris_hfi_gen1_command.c | 48 ++- > .../platform/qcom/iris/iris_hfi_gen1_defines.h | 5 +- > .../platform/qcom/iris/iris_hfi_gen1_response.c | 37 +- > .../platform/qcom/iris/iris_hfi_gen2_command.c | 143 +++++++- > .../platform/qcom/iris/iris_hfi_gen2_defines.h | 5 + > .../platform/qcom/iris/iris_hfi_gen2_response.c | 56 ++- > drivers/media/platform/qcom/iris/iris_hfi_queue.c | 2 +- > drivers/media/platform/qcom/iris/iris_instance.h | 6 + > .../platform/qcom/iris/iris_platform_common.h | 28 +- > .../media/platform/qcom/iris/iris_platform_gen2.c | 198 ++++++++-- > .../platform/qcom/iris/iris_platform_qcs8300.h | 126 +++++-- > .../platform/qcom/iris/iris_platform_sm8250.c | 15 +- > drivers/media/platform/qcom/iris/iris_state.c | 2 +- > drivers/media/platform/qcom/iris/iris_state.h | 1 + > drivers/media/platform/qcom/iris/iris_vb2.c | 18 +- > drivers/media/platform/qcom/iris/iris_vdec.c | 116 +++--- > drivers/media/platform/qcom/iris/iris_vdec.h | 11 + > drivers/media/platform/qcom/iris/iris_vidc.c | 36 +- > drivers/media/platform/qcom/iris/iris_vpu_buffer.c | 397 ++++++++++++++++++++- > drivers/media/platform/qcom/iris/iris_vpu_buffer.h | 46 ++- > 24 files changed, 1159 insertions(+), 211 deletions(-) > --- > base-commit: 398a1b33f1479af35ca915c5efc9b00d6204f8fa > change-id: 20250506-video-iris-hevc-vp9-ee13f23dd9a8 > prerequisite-message-id: <20250417-topic-sm8x50-iris-v10-v7-0-f020cb1d0e98(a)linaro.org> > prerequisite-patch-id: afffe7096c8e110a8da08c987983bc4441d39578 > prerequisite-patch-id: b93c37dc7e09d1631b75387dc1ca90e3066dce17 > prerequisite-patch-id: b7b50aa1657be59fd51c3e53d73382a1ee75a08e > prerequisite-patch-id: 30960743105a36f20b3ec4a9ff19e7bca04d6add > prerequisite-patch-id: 2bba98151ca103aa62a513a0fbd0df7ae64d9868 > prerequisite-patch-id: 0e43a6d758b5fa5ab921c6aa3c19859e312b47d0 > prerequisite-patch-id: 35f8dae1416977e88c2db7c767800c01822e266e > prerequisite-message-id: <20250501-qcs8300_iris-v7-0-b229d5347990(a)quicinc.com> > prerequisite-patch-id: e35b05c527217206ae871aef0d7b0261af0319ea > prerequisite-patch-id: 07ba0745c7d72796567e0a57f5c8e5355a8d2046 > prerequisite-patch-id: 3398937a7fabb45934bb98a530eef73252231132 > prerequisite-patch-id: 500bc3b8391940d3ebca222d2098b737414b2af4 > prerequisite-patch-id: 2e72fe4d11d264db3d42fa450427d30171303c6f > > Best regards,

4 months, 1 week

1
0
0 0

[PATCH v3 0/2] Restrict devmem for confidential VMs

by Dan Williams

Changes since v2 [1]: * Drop the new x86_platform_op and just use cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) directly where needed (Naveen) * Make the restriction identical to lockdown and stop playing games with devmem_is_allowed() * Ensure that CONFIG_IO_STRICT_DEVMEM is enabled to avoid conflicting mappings for userspace mappings of PCI MMIO. The original response to Nikolay's report of an SEPT violation triggered by /dev/mem access to private memory was "let's just turn off /dev/mem". After some machinations of x86_platform_ops to block a subset of problematic access, spelunking the history of devmem_is_allowed() returning "2" to enable some compatibility benefits while blocking access, and discovering that userspace depends buggy kernel behavior for mmap(2) of the first 1MB of memory on x86, the proposal has circled back to "disable /dev/mem". Require both STRICT_DEVMEM and IO_STRICT_DEVMEM for x86 confidential guests to close /dev/mem hole while still allowing for userspace mapping of PCI MMIO as long as the kernel and userspace are not mapping the range at the same time. The range_is_allowed() cleanup is not strictly necessary, but might as well close a 17 year-old "TODO". --- Dan Williams (2): x86/devmem: Remove duplicate range_is_allowed() definition x86/devmem: Drop /dev/mem access for confidential guests arch/x86/Kconfig | 4 ++++ arch/x86/mm/pat/memtype.c | 31 ++++--------------------------- drivers/char/mem.c | 27 +++++++++------------------ include/linux/io.h | 21 +++++++++++++++++++++ 4 files changed, 38 insertions(+), 45 deletions(-) base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8

4 months, 1 week

7
18
0 0

[PATCH] zsmalloc: don't underflow size calculation in zs_obj_write()

by Sergey Senozhatsky

Do not mix class->size and object size during offsets/sizes calculation in zs_obj_write(). Size classes can merge into clusters, based on objects-per-zspage and pages-per-zspage characteristics, so some size classes can store objects smaller than class->size. This becomes problematic when object size is much smaller than class->size - we can determine that object spans two physical pages, because we use a larger class->size for this, while the actual object is much smaller and fits one physical page, so there is nothing to write to the second page and memcpy() size calculation underflows. We always know the exact size in bytes of the object that we are about to write (store), so use it instead of class->size. Reported-by: Igor Belousov <igor.b(a)beldev.am> Cc: <stable(a)vger.kernel.org> Signed-off-by: Sergey Senozhatsky <senozhatsky(a)chromium.org> --- mm/zsmalloc.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c index 70406ac94bbd..999b513c7fdf 100644 --- a/mm/zsmalloc.c +++ b/mm/zsmalloc.c @@ -1233,19 +1233,19 @@ void zs_obj_write(struct zs_pool *pool, unsigned long handle, class = zspage_class(pool, zspage); off = offset_in_page(class->size * obj_idx); - if (off + class->size <= PAGE_SIZE) { + if (!ZsHugePage(zspage)) + off += ZS_HANDLE_SIZE; + + if (off + mem_len <= PAGE_SIZE) { /* this object is contained entirely within a page */ void *dst = kmap_local_zpdesc(zpdesc); - if (!ZsHugePage(zspage)) - off += ZS_HANDLE_SIZE; memcpy(dst + off, handle_mem, mem_len); kunmap_local(dst); } else { /* this object spans two pages */ size_t sizes[2]; - off += ZS_HANDLE_SIZE; sizes[0] = PAGE_SIZE - off; sizes[1] = mem_len - sizes[0]; -- 2.49.0.906.g1f30a19c02-goog

4 months, 1 week

3
4
0 0

[PATCH] dmaengine: mediatek: Fix a possible deadlock error in mtk_cqdma_tx_status()

by Qiu-ji Chen

This patch fixes a potential deadlock bug. We observed that in the mtk-cqdma.c file, most functions like mtk_cqdma_issue_pending() and mtk_cqdma_free_active_desc() follow the correct locking sequence by acquiring the pc lock first before taking the vc lock when handling the vc and pc fields. However, in mtk_cqdma_tx_status(), the function incorrectly acquires the vc lock first before calling mtk_cqdma_find_active_desc(), which subsequently acquires the pc lock. This reversed lock acquisition order (vc → pc) violates the established sequence (pc → vc) and could potentially trigger deadlock scenarios. To resolve this issue, we have moved the vc lock acquisition code from mtk_cqdma_tx_status() into the mtk_cqdma_find_active_desc() function. This adjustment ensures proper lock ordering while maintaining functionality. Since mtk_cqdma_find_active_desc() is a static function with only one call site in mtk_cqdma_tx_status(), this fix effectively addresses the deadlock risk without introducing unintended side effects to other components. This possible bug is found by an experimental static analysis tool developed by our team. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. Fixes: b1f01e48df5a ("dmaengine: mediatek: Add MediaTek Command-Queue DMA controller for MT6765 SoC") Cc: stable(a)vger.kernel.org Signed-off-by: Qiu-ji Chen <chenqiuji666(a)gmail.com> --- drivers/dma/mediatek/mtk-cqdma.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/dma/mediatek/mtk-cqdma.c b/drivers/dma/mediatek/mtk-cqdma.c index d5ddb4e30e71..656354bccb44 100644 --- a/drivers/dma/mediatek/mtk-cqdma.c +++ b/drivers/dma/mediatek/mtk-cqdma.c @@ -423,11 +423,14 @@ static struct virt_dma_desc *mtk_cqdma_find_active_desc(struct dma_chan *c, unsigned long flags; spin_lock_irqsave(&cvc->pc->lock, flags); + spin_lock_irqsave(&cvc->vc.lock, flags); list_for_each_entry(vd, &cvc->pc->queue, node) if (vd->tx.cookie == cookie) { + spin_unlock_irqrestore(&cvc->vc.lock, flags); spin_unlock_irqrestore(&cvc->pc->lock, flags); return vd; } + spin_unlock_irqrestore(&cvc->vc.lock, flags); spin_unlock_irqrestore(&cvc->pc->lock, flags); list_for_each_entry(vd, &cvc->vc.desc_issued, node) @@ -452,9 +455,7 @@ static enum dma_status mtk_cqdma_tx_status(struct dma_chan *c, if (ret == DMA_COMPLETE || !txstate) return ret; - spin_lock_irqsave(&cvc->vc.lock, flags); vd = mtk_cqdma_find_active_desc(c, cookie); - spin_unlock_irqrestore(&cvc->vc.lock, flags); if (vd) { cvd = to_cqdma_vdesc(vd); -- 2.34.1

4 months, 1 week

1
0
0 0

[PATCH 1/3] ASoC: amd: amd_sdw: Fix unlikely uninitialized variable use in create_sdw_dailinks()

by Vijendar Mukunda

Initialize current_be_id to 0 in AMD legacy stack(NO DSP enabled) SoundWire generic machine driver code to handle the unlikely case when there are no devices connected to a DAI. In this case create_sdw_dailink() would return without touching the passed pointer to current_be_id. Found by gcc -fanalyzer Cc: stable(a)vger.kernel.org Fixes: 2981d9b0789c4 ("ASoC: amd: acp: add soundwire machine driver for legacy stack") Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda(a)amd.com> --- sound/soc/amd/acp/acp-sdw-legacy-mach.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/amd/acp/acp-sdw-legacy-mach.c b/sound/soc/amd/acp/acp-sdw-legacy-mach.c index 2020c5cfb3d5..582c68aee6e5 100644 --- a/sound/soc/amd/acp/acp-sdw-legacy-mach.c +++ b/sound/soc/amd/acp/acp-sdw-legacy-mach.c @@ -272,7 +272,7 @@ static int create_sdw_dailinks(struct snd_soc_card *card, /* generate DAI links by each sdw link */ while (soc_dais->initialised) { - int current_be_id; + int current_be_id = 0; ret = create_sdw_dailink(card, soc_dais, dai_links, &current_be_id, codec_conf, sdw_platform_component); -- 2.45.2

4 months, 1 week

2
2
0 0

[PATCH v2 0/4] clk: qcom: Add camera clock controller support for sc8180x

by Satya Priya Kakitapalli

This series adds support for camera clock controller base driver, bindings and DT support on sc8180x platform. Signed-off-by: Satya Priya Kakitapalli <quic_skakitap(a)quicinc.com> --- Changes in v2: - New patch [1/4] to add all the missing gcc bindings along with the required GCC_CAMERA_AHB_CLOCK - As per Konrad's comments, add the camera AHB clock dependency in the DT and yaml bindings. - As per Vladimir's comments, update the Kconfig to add the SC8180X config in correct alphanumerical order. - Link to v1: https://lore.kernel.org/r/20250422-sc8180x-camcc-support-v1-0-691614d13f06@… --- Satya Priya Kakitapalli (4): dt-bindings: clock: qcom: Add missing bindings on gcc-sc8180x dt-bindings: clock: Add Qualcomm SC8180X Camera clock controller clk: qcom: camcc-sc8180x: Add SC8180X camera clock controller driver arm64: dts: qcom: Add camera clock controller for sc8180x .../bindings/clock/qcom,sc8180x-camcc.yaml | 67 + arch/arm64/boot/dts/qcom/sc8180x.dtsi | 14 + drivers/clk/qcom/Kconfig | 10 + drivers/clk/qcom/Makefile | 1 + drivers/clk/qcom/camcc-sc8180x.c | 2897 ++++++++++++++++++++ include/dt-bindings/clock/qcom,gcc-sc8180x.h | 12 + include/dt-bindings/clock/qcom,sc8180x-camcc.h | 181 ++ 7 files changed, 3182 insertions(+) --- base-commit: bc8aa6cdadcc00862f2b5720e5de2e17f696a081 change-id: 20250422-sc8180x-camcc-support-9a82507d2a39 Best regards, -- Satya Priya Kakitapalli <quic_skakitap(a)quicinc.com>

4 months, 1 week

3
6
0 0

[PATCH 2/2] phy: tegra: xusb: Disable periodic tracking on Tegra234

by Wayne Chang

From: Haotien Hsu <haotienh(a)nvidia.com> Periodic calibration updates (~10µs) may overlap with transfers when PCIe NVMe SSD, LPDDR, and USB2 devices operate simultaneously, causing crosstalk on Tegra234 devices. Hence disable periodic calibration updates and make this a one-time calibration. Fixes: d8163a32ca95 ("phy: tegra: xusb: Add Tegra234 support") Cc: stable(a)vger.kernel.org Signed-off-by: Haotien Hsu <haotienh(a)nvidia.com> Signed-off-by: Wayne Chang <waynec(a)nvidia.com> --- drivers/phy/tegra/xusb-tegra186.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/phy/tegra/xusb-tegra186.c b/drivers/phy/tegra/xusb-tegra186.c index dd0aaf305e90..414f4eabfe9d 100644 --- a/drivers/phy/tegra/xusb-tegra186.c +++ b/drivers/phy/tegra/xusb-tegra186.c @@ -1703,7 +1703,7 @@ const struct tegra_xusb_padctl_soc tegra234_xusb_padctl_soc = { .num_supplies = ARRAY_SIZE(tegra194_xusb_padctl_supply_names), .supports_gen2 = true, .poll_trk_completed = true, - .trk_hw_mode = true, + .trk_hw_mode = false, .trk_update_on_idle = true, .supports_lp_cfg_en = true, }; -- 2.25.1

4 months, 1 week

1
0
0 0

[PATCH 02/14] drm/amd/display: Correct the reply value when AUX write incomplete

by Ray Wu

From: Wayne Lin <Wayne.Lin(a)amd.com> [Why] Now forcing aux->transfer to return 0 when incomplete AUX write is inappropriate. It should return bytes have been transferred. [How] aux->transfer is asked not to change original msg except reply field of drm_dp_aux_msg structure. Copy the msg->buffer when it's write request, and overwrite the first byte when sink reply 1 byte indicating partially written byte number. Then we can return the correct value without changing the original msg. Fixes: 6285f12bc54c ("drm/amd/display: Fix wrong handling for AUX_DEFER case") Cc: stable(a)vger.kernel.org Cc: Mario Limonciello <mario.limonciello(a)amd.com> Cc: Alex Deucher <alexander.deucher(a)amd.com> Reviewed-by: Ray Wu <ray.wu(a)amd.com> Signed-off-by: Wayne Lin <Wayne.Lin(a)amd.com> Signed-off-by: Ray Wu <ray.wu(a)amd.com> --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ++- .../drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 10 ++++++++-- 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 8984e211dd1c..36c16030fca9 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -12853,7 +12853,8 @@ int amdgpu_dm_process_dmub_aux_transfer_sync( /* The reply is stored in the top nibble of the command. */ payload->reply[0] = (adev->dm.dmub_notify->aux_reply.command >> 4) & 0xF; - if (!payload->write && p_notify->aux_reply.length) + /*write req may receive a byte indicating partially written number as well*/ + if (p_notify->aux_reply.length) memcpy(payload->data, p_notify->aux_reply.data, p_notify->aux_reply.length); diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c index d19aea595722..0d7b72c75802 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c @@ -62,6 +62,7 @@ static ssize_t dm_dp_aux_transfer(struct drm_dp_aux *aux, enum aux_return_code_type operation_result; struct amdgpu_device *adev; struct ddc_service *ddc; + uint8_t copy[16]; if (WARN_ON(msg->size > 16)) return -E2BIG; @@ -77,6 +78,11 @@ static ssize_t dm_dp_aux_transfer(struct drm_dp_aux *aux, (msg->request & DP_AUX_I2C_WRITE_STATUS_UPDATE) != 0; payload.defer_delay = 0; + if (payload.write) { + memcpy(copy, msg->buffer, msg->size); + payload.data = copy; + } + result = dc_link_aux_transfer_raw(TO_DM_AUX(aux)->ddc_service, &payload, &operation_result); @@ -100,9 +106,9 @@ static ssize_t dm_dp_aux_transfer(struct drm_dp_aux *aux, */ if (payload.write && result >= 0) { if (result) { - /*one byte indicating partially written bytes. Force 0 to retry*/ + /*one byte indicating partially written bytes*/ drm_info(adev_to_drm(adev), "amdgpu: AUX partially written\n"); - result = 0; + result = payload.data[0]; } else if (!payload.reply[0]) /*I2C_ACK|AUX_ACK*/ result = msg->size; -- 2.43.0

4 months, 1 week

1
0
0 0

[REGRESSION][BISECTED][STABLE] MT7925: mDNS and IPv6 broken in kernel 6.14.3 and above

by fossben＠pm.me

Hello all, After upgrading to 6.14.3 on my PC with a MT7925 chip, I noticed that I could no longer ping *.local addresses provided by Avahi. In addition, I also noticed that I was not able to get a DHCP IPv6 address from my router, no matter how many times I rebooted the router or reconnected with NetworkManager. Reverting to 6.14.2 fixes both mDNS and IPv6 addresses immediately. Going back to 6.14.3 immediately breaks mDNS again, but the IPv6 address will stay there for a while before disappearing later, possibly because the DHCP lease expired? I am not sure exactly when it stops working. I've done a kernel bisect between 6.14.2 and 6.14.3 and found the offending commit that causes mDNS to fail: commit 80007d3f92fd018d0a052a706400e976b36e3c87 Author: Ming Yen Hsieh <mingyen.hsieh(a)mediatek.com> Date: Tue Mar 4 16:08:50 2025 -0800 wifi: mt76: mt7925: integrate *mlo_sta_cmd and *sta_cmd commit cb1353ef34735ec1e5d9efa1fe966f05ff1dc1e1 upstream. Integrate *mlo_sta_cmd and *sta_cmd for the MLO firmware. Fixes: 86c051f2c418 ("wifi: mt76: mt7925: enabling MLO when the firmware supports it") drivers/net/wireless/mediatek/mt76/mt7925/mcu.c | 59 ++++------------------------------------------------------- 1 file changed, 4 insertions(+), 55 deletions(-) I do not know if this same commit is also causing the IPv6 issues as testing that requires quite a bit of time to reproduce. What I do know with certainty as of this moment is that it definitely breaks in kernel 6.14.3. I've attached my hardware info as well as dmesg logs from the last working kernel from the bisect and 6.14.4 which exhibits the issue. Please let me know if there's any other info you need. Thanks! Benjamin Xiao

4 months, 1 week

3
9
0 0

[PATCH v2] usb: typec: tcpm: move tcpm_queue_vdm_unlocked to asynchronous work

by RD Babiera

A state check was previously added to tcpm_queue_vdm_unlocked to prevent a deadlock where the DisplayPort Alt Mode driver would be executing work and attempting to grab the tcpm_lock while the TCPM was holding the lock and attempting to unregister the altmode, blocking on the altmode driver's cancel_work_sync call. Because the state check isn't protected, there is a small window where the Alt Mode driver could determine that the TCPM is in a ready state and attempt to grab the lock while the TCPM grabs the lock and changes the TCPM state to one that causes the deadlock. The callstack is provided below: [110121.667392][ C7] Call trace: [110121.667396][ C7] __switch_to+0x174/0x338 [110121.667406][ C7] __schedule+0x608/0x9f0 [110121.667414][ C7] schedule+0x7c/0xe8 [110121.667423][ C7] kernfs_drain+0xb0/0x114 [110121.667431][ C7] __kernfs_remove+0x16c/0x20c [110121.667436][ C7] kernfs_remove_by_name_ns+0x74/0xe8 [110121.667442][ C7] sysfs_remove_group+0x84/0xe8 [110121.667450][ C7] sysfs_remove_groups+0x34/0x58 [110121.667458][ C7] device_remove_groups+0x10/0x20 [110121.667464][ C7] device_release_driver_internal+0x164/0x2e4 [110121.667475][ C7] device_release_driver+0x18/0x28 [110121.667484][ C7] bus_remove_device+0xec/0x118 [110121.667491][ C7] device_del+0x1e8/0x4ac [110121.667498][ C7] device_unregister+0x18/0x38 [110121.667504][ C7] typec_unregister_altmode+0x30/0x44 [110121.667515][ C7] tcpm_reset_port+0xac/0x370 [110121.667523][ C7] tcpm_snk_detach+0x84/0xb8 [110121.667529][ C7] run_state_machine+0x4c0/0x1b68 [110121.667536][ C7] tcpm_state_machine_work+0x94/0xe4 [110121.667544][ C7] kthread_worker_fn+0x10c/0x244 [110121.667552][ C7] kthread+0x104/0x1d4 [110121.667557][ C7] ret_from_fork+0x10/0x20 [110121.667689][ C7] Workqueue: events dp_altmode_work [110121.667697][ C7] Call trace: [110121.667701][ C7] __switch_to+0x174/0x338 [110121.667710][ C7] __schedule+0x608/0x9f0 [110121.667717][ C7] schedule+0x7c/0xe8 [110121.667725][ C7] schedule_preempt_disabled+0x24/0x40 [110121.667733][ C7] __mutex_lock+0x408/0xdac [110121.667741][ C7] __mutex_lock_slowpath+0x14/0x24 [110121.667748][ C7] mutex_lock+0x40/0xec [110121.667757][ C7] tcpm_altmode_enter+0x78/0xb4 [110121.667764][ C7] typec_altmode_enter+0xdc/0x10c [110121.667769][ C7] dp_altmode_work+0x68/0x164 [110121.667775][ C7] process_one_work+0x1e4/0x43c [110121.667783][ C7] worker_thread+0x25c/0x430 [110121.667789][ C7] kthread+0x104/0x1d4 [110121.667794][ C7] ret_from_fork+0x10/0x20 Change tcpm_queue_vdm_unlocked to queue for tcpm_queue_vdm_work, which can perform the state check while holding the TCPM lock while the Alt Mode lock is no longer held. This requires a new struct to hold the vdm data, altmode_vdm_event. Fixes: cdc9946ea637 ("usb: typec: tcpm: enforce ready state when queueing alt mode vdm") Cc: stable(a)vger.kernel.org Signed-off-by: RD Babiera <rdbabiera(a)google.com> Reviewed-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com> --- Changes from v1: * modified commit message to include call stack --- drivers/usb/typec/tcpm/tcpm.c | 91 +++++++++++++++++++++++++++-------- 1 file changed, 71 insertions(+), 20 deletions(-) diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c index 784fa23102f9..9b8d98328ddb 100644 --- a/drivers/usb/typec/tcpm/tcpm.c +++ b/drivers/usb/typec/tcpm/tcpm.c @@ -597,6 +597,15 @@ struct pd_rx_event { enum tcpm_transmit_type rx_sop_type; }; +struct altmode_vdm_event { + struct kthread_work work; + struct tcpm_port *port; + u32 header; + u32 *data; + int cnt; + enum tcpm_transmit_type tx_sop_type; +}; + static const char * const pd_rev[] = { [PD_REV10] = "rev1", [PD_REV20] = "rev2", @@ -1610,18 +1619,68 @@ static void tcpm_queue_vdm(struct tcpm_port *port, const u32 header, mod_vdm_delayed_work(port, 0); } -static void tcpm_queue_vdm_unlocked(struct tcpm_port *port, const u32 header, - const u32 *data, int cnt, enum tcpm_transmit_type tx_sop_type) +static void tcpm_queue_vdm_work(struct kthread_work *work) { - if (port->state != SRC_READY && port->state != SNK_READY && - port->state != SRC_VDM_IDENTITY_REQUEST) - return; + struct altmode_vdm_event *event = container_of(work, + struct altmode_vdm_event, + work); + struct tcpm_port *port = event->port; mutex_lock(&port->lock); - tcpm_queue_vdm(port, header, data, cnt, tx_sop_type); + if (port->state != SRC_READY && port->state != SNK_READY && + port->state != SRC_VDM_IDENTITY_REQUEST) { + tcpm_log_force(port, "dropping altmode_vdm_event"); + goto port_unlock; + } + + tcpm_queue_vdm(port, event->header, event->data, event->cnt, event->tx_sop_type); + +port_unlock: + kfree(event->data); + kfree(event); mutex_unlock(&port->lock); } +static int tcpm_queue_vdm_unlocked(struct tcpm_port *port, const u32 header, + const u32 *data, int cnt, enum tcpm_transmit_type tx_sop_type) +{ + struct altmode_vdm_event *event; + u32 *data_cpy; + int ret = -ENOMEM; + + event = kzalloc(sizeof(*event), GFP_KERNEL); + if (!event) + goto err_event; + + data_cpy = kcalloc(cnt, sizeof(u32), GFP_KERNEL); + if (!data_cpy) + goto err_data; + + kthread_init_work(&event->work, tcpm_queue_vdm_work); + event->port = port; + event->header = header; + memcpy(data_cpy, data, sizeof(u32) * cnt); + event->data = data_cpy; + event->cnt = cnt; + event->tx_sop_type = tx_sop_type; + + ret = kthread_queue_work(port->wq, &event->work); + if (!ret) { + ret = -EBUSY; + goto err_queue; + } + + return 0; + +err_queue: + kfree(data_cpy); +err_data: + kfree(event); +err_event: + tcpm_log_force(port, "failed to queue altmode vdm, err:%d", ret); + return ret; +} + static void svdm_consume_identity(struct tcpm_port *port, const u32 *p, int cnt) { u32 vdo = p[VDO_INDEX_IDH]; @@ -2832,8 +2891,7 @@ static int tcpm_altmode_enter(struct typec_altmode *altmode, u32 *vdo) header = VDO(altmode->svid, vdo ? 2 : 1, svdm_version, CMD_ENTER_MODE); header |= VDO_OPOS(altmode->mode); - tcpm_queue_vdm_unlocked(port, header, vdo, vdo ? 1 : 0, TCPC_TX_SOP); - return 0; + return tcpm_queue_vdm_unlocked(port, header, vdo, vdo ? 1 : 0, TCPC_TX_SOP); } static int tcpm_altmode_exit(struct typec_altmode *altmode) @@ -2849,8 +2907,7 @@ static int tcpm_altmode_exit(struct typec_altmode *altmode) header = VDO(altmode->svid, 1, svdm_version, CMD_EXIT_MODE); header |= VDO_OPOS(altmode->mode); - tcpm_queue_vdm_unlocked(port, header, NULL, 0, TCPC_TX_SOP); - return 0; + return tcpm_queue_vdm_unlocked(port, header, NULL, 0, TCPC_TX_SOP); } static int tcpm_altmode_vdm(struct typec_altmode *altmode, @@ -2858,9 +2915,7 @@ static int tcpm_altmode_vdm(struct typec_altmode *altmode, { struct tcpm_port *port = typec_altmode_get_drvdata(altmode); - tcpm_queue_vdm_unlocked(port, header, data, count - 1, TCPC_TX_SOP); - - return 0; + return tcpm_queue_vdm_unlocked(port, header, data, count - 1, TCPC_TX_SOP); } static const struct typec_altmode_ops tcpm_altmode_ops = { @@ -2884,8 +2939,7 @@ static int tcpm_cable_altmode_enter(struct typec_altmode *altmode, enum typec_pl header = VDO(altmode->svid, vdo ? 2 : 1, svdm_version, CMD_ENTER_MODE); header |= VDO_OPOS(altmode->mode); - tcpm_queue_vdm_unlocked(port, header, vdo, vdo ? 1 : 0, TCPC_TX_SOP_PRIME); - return 0; + return tcpm_queue_vdm_unlocked(port, header, vdo, vdo ? 1 : 0, TCPC_TX_SOP_PRIME); } static int tcpm_cable_altmode_exit(struct typec_altmode *altmode, enum typec_plug_index sop) @@ -2901,8 +2955,7 @@ static int tcpm_cable_altmode_exit(struct typec_altmode *altmode, enum typec_plu header = VDO(altmode->svid, 1, svdm_version, CMD_EXIT_MODE); header |= VDO_OPOS(altmode->mode); - tcpm_queue_vdm_unlocked(port, header, NULL, 0, TCPC_TX_SOP_PRIME); - return 0; + return tcpm_queue_vdm_unlocked(port, header, NULL, 0, TCPC_TX_SOP_PRIME); } static int tcpm_cable_altmode_vdm(struct typec_altmode *altmode, enum typec_plug_index sop, @@ -2910,9 +2963,7 @@ static int tcpm_cable_altmode_vdm(struct typec_altmode *altmode, enum typec_plug { struct tcpm_port *port = typec_altmode_get_drvdata(altmode); - tcpm_queue_vdm_unlocked(port, header, data, count - 1, TCPC_TX_SOP_PRIME); - - return 0; + return tcpm_queue_vdm_unlocked(port, header, data, count - 1, TCPC_TX_SOP_PRIME); } static const struct typec_cable_ops tcpm_cable_ops = { base-commit: 588d032e9e566997db3213dee145dbe3bda297b6 -- 2.49.0.967.g6a0df3ecc3-goog

4 months, 1 week

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2025