- Linux-stable-mirror - lists.linaro.org

FAILED: patch "[PATCH] PCI/MSI: Add an option to write MSIX ENTRY_DATA before any" failed to apply to 6.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.14.y git checkout FETCH_HEAD git cherry-pick -x cf761e3dacc6ad5f65a4886d00da1f9681e6805a # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025042118-marshland-subsystem-ac15@gregkh' --subject-prefix 'PATCH 6.14.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From cf761e3dacc6ad5f65a4886d00da1f9681e6805a Mon Sep 17 00:00:00 2001 From: Jonathan Currier <dullfire(a)yahoo.com> Date: Sun, 17 Nov 2024 17:48:42 -0600 Subject: [PATCH] PCI/MSI: Add an option to write MSIX ENTRY_DATA before any reads Commit 7d5ec3d36123 ("PCI/MSI: Mask all unused MSI-X entries") introduced a readl() from ENTRY_VECTOR_CTRL before the writel() to ENTRY_DATA. This is correct, however some hardware, like the Sun Neptune chips, the NIU module, will cause an error and/or fatal trap if any MSIX table entry is read before the corresponding ENTRY_DATA field is written to. Add an optional early writel() in msix_prepare_msi_desc(). Fixes: 7d5ec3d36123 ("PCI/MSI: Mask all unused MSI-X entries") Signed-off-by: Jonathan Currier <dullfire(a)yahoo.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/all/20241117234843.19236-2-dullfire@yahoo.com diff --git a/drivers/pci/msi/msi.c b/drivers/pci/msi/msi.c index 6569ba3577fe..8b8848788618 100644 --- a/drivers/pci/msi/msi.c +++ b/drivers/pci/msi/msi.c @@ -615,6 +615,9 @@ void msix_prepare_msi_desc(struct pci_dev *dev, struct msi_desc *desc) void __iomem *addr = pci_msix_desc_addr(desc); desc->pci.msi_attrib.can_mask = 1; + /* Workaround for SUN NIU insanity, which requires write before read */ + if (dev->dev_flags & PCI_DEV_FLAGS_MSIX_TOUCH_ENTRY_DATA_FIRST) + writel(0, addr + PCI_MSIX_ENTRY_DATA); desc->pci.msix_ctrl = readl(addr + PCI_MSIX_ENTRY_VECTOR_CTRL); } } diff --git a/include/linux/pci.h b/include/linux/pci.h index 0e8e3fd77e96..51e2bd6405cd 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -245,6 +245,8 @@ enum pci_dev_flags { PCI_DEV_FLAGS_NO_RELAXED_ORDERING = (__force pci_dev_flags_t) (1 << 11), /* Device does honor MSI masking despite saying otherwise */ PCI_DEV_FLAGS_HAS_MSI_MASKING = (__force pci_dev_flags_t) (1 << 12), + /* Device requires write to PCI_MSIX_ENTRY_DATA before any MSIX reads */ + PCI_DEV_FLAGS_MSIX_TOUCH_ENTRY_DATA_FIRST = (__force pci_dev_flags_t) (1 << 13), }; enum pci_irq_reroute_variant {

1 week

1
0
0 0

[PATCH 00/20] Add support for HEVC and VP9 codecs in decoder

by Dikshita Agarwal

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 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@… 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 [1] [1]: 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 - 1 testcase failed as bitstream is invalid (this fails with reference as well) - RAP_B_Bossen_2 - 1 testcase failed due to CRC mismatch - RAP_A_docomo_6 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 (fails with ref decoder as well) - vp90-2-22-svc_1280x720_3.ivf - 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 Note: There is a timing issue with the clips having multiple resolution change. Where firmware returned all the buffers with previous sequence and has no buffer left to attach the LAST flag to. At the same time, client is not queueing any further buffers, so there is deadlock where client is waiting for LAST flag, while firmware doesn't have any capture buffer to attach LAST flag to. Ideally client should keep queueing the buffers on capture queue untill the LAST flag is received. The result of fluster test on SM8250: 132/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 - 1 testcase failed as bitstream is invalid (this fails with reference as well) - RAP_B_Bossen_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 (fails with ref decoder as well) - vp90-2-22-svc_1280x720_3.ivf - 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. Note: Same timing issue as observed on SM8550 is seen on SM8250 as well. Signed-off-by: Dikshita Agarwal <quic_dikshita(a)quicinc.com> --- Dikshita Agarwal (20): media: iris: Skip destroying internal buffer if not dequeued media: iris: Update CAPTURE format info based on OUTPUT format media: iris: Add handling for corrupt and drop frames media: iris: Avoid updating frame size to firmware during reconfig media: iris: Send V4L2_BUF_FLAG_ERROR for buffers with 0 filled length media: iris: Add handling for no show frames media: iris: Improve last flag handling media: iris: Skip flush on first sequence change media: iris: Prevent HFI queue writes when core is in deinit state media: iris: Remove redundant buffer count check in stream off 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: 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 | 22 +- 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 | 44 ++- .../platform/qcom/iris/iris_hfi_gen1_defines.h | 5 +- .../platform/qcom/iris/iris_hfi_gen1_response.c | 22 +- .../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 | 57 ++- 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 +- .../platform/qcom/iris/iris_platform_sm8250.c | 15 +- .../platform/qcom/iris/iris_platform_sm8550.c | 143 +++++++- drivers/media/platform/qcom/iris/iris_vb2.c | 3 +- drivers/media/platform/qcom/iris/iris_vdec.c | 113 +++--- drivers/media/platform/qcom/iris/iris_vdec.h | 11 + drivers/media/platform/qcom/iris/iris_vidc.c | 3 - drivers/media/platform/qcom/iris/iris_vpu_buffer.c | 397 ++++++++++++++++++++- drivers/media/platform/qcom/iris/iris_vpu_buffer.h | 46 ++- 20 files changed, 948 insertions(+), 153 deletions(-) --- base-commit: 7824b91d23e9f255f0e9d2acaa74265c9cac2e9c change-id: 20250402-iris-dec-hevc-vp9-2654a1fc4d0d Best regards, -- Dikshita Agarwal <quic_dikshita(a)quicinc.com>

1 week

6
23
0 0

ISE 2025 Attendee's Contacts Inside!

by Nancy Doll

Hi, Are you looking for the most recent attendee and exhibitor lists for Integrated Systems Europe (ISE) 2025? Our updated database includes even the latest sign-ups, giving you accurate, real-time insights for your outreach. Event Snapshot: Fira Barcelona Gran Via, Barcelona, Spain Exhibitors: 1,460 Attendees: 74,591 Available Data Fields: Induvial Email address, Phone Number, Contact Name, Job Title, Company Name, Company website, Physical Address and more), Would you like to receive information on the attendee list, exhibitor list, or both? I’d be happy to provide pricing and answer any questions you may have. Looking forward to connecting with you! Warm regards, Nancy Doll Senior Demand Generation Specialist P.S. Prefer not to receive updates? Just reply with “NO,” and I’ll make sure you’re removed.

1 week

1
0
0 0

[PATCH 0/9] fs: harden anon inodes

by Christian Brauner

* Anonymous inodes currently don't come with a proper mode causing issues in the kernel when we want to add useful VFS debug assert. Fix that by giving them a proper mode and masking it off when we report it to userspace which relies on them not having any mode. * Anonymous inodes currently allow to change inode attributes because the VFS falls back to simple_setattr() if i_op->setattr isn't implemented. This means the ownership and mode for every single user of anon_inode_inode can be changed. Block that as it's either useless or actively harmful. If specific ownership is needed the respective subsystem should allocate anonymous inodes from their own private superblock. * Port pidfs to the new anon_inode_{g,s}etattr() helpers. * Add proper tests for anonymous inode behavior. The anonymous inode specific fixes should ideally be backported to all LTS kernels. Signed-off-by: Christian Brauner <brauner(a)kernel.org> --- Christian Brauner (9): anon_inode: use a proper mode internally pidfs: use anon_inode_getattr() anon_inode: explicitly block ->setattr() pidfs: use anon_inode_setattr() anon_inode: raise SB_I_NODEV and SB_I_NOEXEC selftests/filesystems: add first test for anonymous inodes selftests/filesystems: add second test for anonymous inodes selftests/filesystems: add third test for anonymous inodes selftests/filesystems: add fourth test for anonymous inodes fs/anon_inodes.c | 45 ++++++++++++++ fs/internal.h | 5 ++ fs/libfs.c | 2 +- fs/pidfs.c | 26 +------- tools/testing/selftests/filesystems/.gitignore | 1 + tools/testing/selftests/filesystems/Makefile | 2 +- .../selftests/filesystems/anon_inode_test.c | 69 ++++++++++++++++++++++ 7 files changed, 124 insertions(+), 26 deletions(-) --- base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8 change-id: 20250407-work-anon_inode-e22bb1a74992

1 week

7
18
0 0

[PATCH] drm/tegra: Assign plane type before registration

by Aaron Kling via B4 Relay

From: Thierry Reding <treding(a)nvidia.com> Changes to a plane's type after it has been registered aren't propagated to userspace automatically. This could possibly be achieved by updating the property, but since we can already determine which type this should be before the registration, passing in the right type from the start is a much better solution. Suggested-by: Aaron Kling <webgeek1234(a)gmail.com> Signed-off-by: Thierry Reding <treding(a)nvidia.com> Cc: stable(a)vger.kernel.org --- Signed-off-by: Aaron Kling <webgeek1234(a)gmail.com> --- drivers/gpu/drm/tegra/dc.c | 12 ++++++++---- drivers/gpu/drm/tegra/hub.c | 4 ++-- drivers/gpu/drm/tegra/hub.h | 3 ++- 3 files changed, 12 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c index 798507a8ae56d6789feb95dccdd23b2e63d9c148..56f12dbcee3e93ff5e4804e5fe9b23f160073ebf 100644 --- a/drivers/gpu/drm/tegra/dc.c +++ b/drivers/gpu/drm/tegra/dc.c @@ -1321,10 +1321,16 @@ static struct drm_plane *tegra_dc_add_shared_planes(struct drm_device *drm, if (wgrp->dc == dc->pipe) { for (j = 0; j < wgrp->num_windows; j++) { unsigned int index = wgrp->windows[j]; + enum drm_plane_type type; + + if (primary) + type = DRM_PLANE_TYPE_OVERLAY; + else + type = DRM_PLANE_TYPE_PRIMARY; plane = tegra_shared_plane_create(drm, dc, wgrp->index, - index); + index, type); if (IS_ERR(plane)) return plane; @@ -1332,10 +1338,8 @@ static struct drm_plane *tegra_dc_add_shared_planes(struct drm_device *drm, * Choose the first shared plane owned by this * head as the primary plane. */ - if (!primary) { - plane->type = DRM_PLANE_TYPE_PRIMARY; + if (!primary) primary = plane; - } } } } diff --git a/drivers/gpu/drm/tegra/hub.c b/drivers/gpu/drm/tegra/hub.c index fa6140fc37fb16df4b150e5ae9d8148f8f446cd7..8f779f23dc0904d38b14d3f3a928a07fc9e601ad 100644 --- a/drivers/gpu/drm/tegra/hub.c +++ b/drivers/gpu/drm/tegra/hub.c @@ -755,9 +755,9 @@ static const struct drm_plane_helper_funcs tegra_shared_plane_helper_funcs = { struct drm_plane *tegra_shared_plane_create(struct drm_device *drm, struct tegra_dc *dc, unsigned int wgrp, - unsigned int index) + unsigned int index, + enum drm_plane_type type) { - enum drm_plane_type type = DRM_PLANE_TYPE_OVERLAY; struct tegra_drm *tegra = drm->dev_private; struct tegra_display_hub *hub = tegra->hub; struct tegra_shared_plane *plane; diff --git a/drivers/gpu/drm/tegra/hub.h b/drivers/gpu/drm/tegra/hub.h index 23c4b2115ed1e36e8d2d6ed614a6ead97eb4c441..a66f18c4facc9df96ea8b9f54239b52f06536d12 100644 --- a/drivers/gpu/drm/tegra/hub.h +++ b/drivers/gpu/drm/tegra/hub.h @@ -80,7 +80,8 @@ void tegra_display_hub_cleanup(struct tegra_display_hub *hub); struct drm_plane *tegra_shared_plane_create(struct drm_device *drm, struct tegra_dc *dc, unsigned int wgrp, - unsigned int index); + unsigned int index, + enum drm_plane_type type); int tegra_display_hub_atomic_check(struct drm_device *drm, struct drm_atomic_state *state); --- base-commit: 119009db267415049182774196e3cce9e13b52ef change-id: 20250419-tegra-drm-primary-ce47febefdaf Best regards, -- Aaron Kling <webgeek1234(a)gmail.com>

1 week

3
2
0 0

BUG: perf hardware breakpoint pc value mismatch

by liaochen (A)

Hi all, We found the following issue with Linux v6.12-rc7 on KunPeng920 platform. A very low frequency problem of pc value mismatch occurs when using perf hardware breakpoints to trigger a signal handler and comparing pc from u_context with its desired value. Attached please find the reproducer for this issue. It applies perf events to set a hardware breakpoint to an address while binding a signal to the perf event fd. When stepping into the breakpoint address, the signal handler compares pc value copied from signal ucontext with the real breakpoint address and see if there is a mismatch. While looking into the flow of execution: // normal flow of exe: a.out-19844 [038] d... 8763.348609: hw_breakpoint_control: perf user addr: 400c6c, bp addr: 400c6c, ops: 0 // breakpoint exception: a.out-19844 [038] d... 8763.348611: do_debug_exception: ec: 0, pc: 400c6c, pstate: 20001000 a.out-19844 [038] d... 8763.348611: breakpoint_handler: perf bp read: 400c6c // send signal: a.out-19844 [038] d.h. 8763.348613: send_sigio_to_task <-send_sigio a.out-19844 [038] d.h. 8763.348614: <stack trace> => send_sigio_to_task => send_sigio => kill_fasync_rcu => kill_fasync => perf_event_wakeup => perf_pending_event => irq_work_single => irq_work_run_list => irq_work_run => do_handle_IPI => ipi_handler => handle_percpu_devid_fasteoi_ipi => __handle_domain_irq => gic_handle_irq => el0_irq_naked a.out-19844 [038] d.h. 8763.348614: send_sigio_to_task: step in with signum 38 a.out-19844 [038] d.h. 8763.348615: send_sigio_to_task: will do_send_sig_info 38 // kernel signal handling: a.out-19844 [038] .... 8763.348616: do_notify_resume: thread_flags 2097665, _TIF_SIGPENDING 1, _TIF_NOTIFY_SIGNAL40 a.out-19844 [038] .... 8763.348617: setup_sigframe: restore sig: 400c6c // single step exception: a.out-19844 [038] d... 8763.348619: do_debug_exception: ec: 1, pc: 400988, pstate: 20001000 a.out-19844 [038] d... 8763.348621: hw_breakpoint_control: perf user addr: 400c6c, bp addr: 400c6c, ops: 1 // abnormal flow of exe: a.out-19844 [084] d... 8763.782103: hw_breakpoint_control: perf user addr: 400c6c, bp addr: 400c6c, ops: 0 // breakpoint exception: a.out-19844 [084] d... 8763.782104: do_debug_exception: ec: 0, pc: 400c6c, pstate: 20001000 // single step exception: a.out-19844 [084] d... 8763.782105: breakpoint_handler: perf bp read: 400c6c a.out-19844 [084] d... 8763.782107: do_debug_exception: ec: 1, pc: 400c70, pstate: 20001000 // send signal: a.out-19844 [084] d.h. 8763.782108: send_sigio_to_task <-send_sigio a.out-19844 [084] d.h. 8763.782109: <stack trace> => send_sigio_to_task => send_sigio => kill_fasync_rcu => kill_fasync => perf_event_wakeup => perf_pending_event => irq_work_single => irq_work_run_list => irq_work_run => do_handle_IPI => ipi_handler => handle_percpu_devid_fasteoi_ipi => __handle_domain_irq => gic_handle_irq => el0_irq_naked a.out-19844 [084] d.h. 8763.782110: send_sigio_to_task: step in with signum 38 a.out-19844 [084] d.h. 8763.782110: send_sigio_to_task: will do_send_sig_info 38 // kernel signal handling: a.out-19844 [084] .... 8763.782111: do_notify_resume: thread_flags 513, _TIF_SIGPENDING 1, _TIF_NOTIFY_SIGNAL40 a.out-19844 [084] .... 8763.782113: setup_sigframe: restore sig: 400c70 a.out-19844 [084] d... 8763.782115: hw_breakpoint_control: perf user addr: 400c6c, bp addr: 400c6c, ops: 1 Kernel sends this signal to task through pushing a perf_pending_event (which sends the signal) in irq_work_queue then triggering an IPI to let kernel handle this pended task. seems that when mismatch occurs, the IPI does not preempt the breakpoint exception it should preempt, causing no pending signals to be handled. In this way, there is no pending signals in do_notify_resume and kernel will not set up signal frame with correct pc value. Thanks, Chen

1 week

1
1
0 0

[PATCH v2] usb: cdnsp: Fix issue with resuming from L1

by Pawel Laszczak

In very rare cases after resuming controller from L1 to L0 it reads registers before the clock UTMI have been enabled and as the result driver reads incorrect value. Most of registers are in APB domain clock but some of them (e.g. PORTSC) are in UTMI domain clock. After entering to L1 state the UTMI clock can be disabled. When controller transition from L1 to L0 the port status change event is reported and in interrupt runtime function driver reads PORTSC. During this read operation controller synchronize UTMI and APB domain but UTMI clock is still disabled and in result it reads 0xFFFFFFFF value. To fix this issue driver increases APB timeout value. The issue is platform specific and if the default value of APB timeout is not sufficient then this time should be set Individually for each platform. Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver") cc: stable(a)vger.kernel.org Signed-off-by: Pawel Laszczak <pawell(a)cadence.com> --- Changelog: v2: - changed patch description - made patch as platform specific drivers/usb/cdns3/cdnsp-gadget.c | 29 +++++++++++++++++++++++++++++ drivers/usb/cdns3/cdnsp-gadget.h | 3 +++ drivers/usb/cdns3/cdnsp-pci.c | 12 ++++++++++-- drivers/usb/cdns3/core.h | 3 +++ 4 files changed, 45 insertions(+), 2 deletions(-) diff --git a/drivers/usb/cdns3/cdnsp-gadget.c b/drivers/usb/cdns3/cdnsp-gadget.c index 87f310841735..7f5534db2086 100644 --- a/drivers/usb/cdns3/cdnsp-gadget.c +++ b/drivers/usb/cdns3/cdnsp-gadget.c @@ -139,6 +139,26 @@ static void cdnsp_clear_port_change_bit(struct cdnsp_device *pdev, (portsc & PORT_CHANGE_BITS), port_regs); } +static void cdnsp_set_apb_timeout_value(struct cdnsp_device *pdev) +{ + struct cdns *cdns = dev_get_drvdata(pdev->dev); + __le32 __iomem *reg; + void __iomem *base; + u32 offset = 0; + u32 val; + + if (!cdns->override_apb_timeout) + return; + + base = &pdev->cap_regs->hc_capbase; + offset = cdnsp_find_next_ext_cap(base, offset, D_XEC_PRE_REGS_CAP); + reg = base + offset + REG_CHICKEN_BITS_3_OFFSET; + + val = le32_to_cpu(readl(reg)); + val = CHICKEN_APB_TIMEOUT_SET(val, cdns->override_apb_timeout); + writel(cpu_to_le32(val), reg); +} + static void cdnsp_set_chicken_bits_2(struct cdnsp_device *pdev, u32 bit) { __le32 __iomem *reg; @@ -1798,6 +1818,15 @@ static int cdnsp_gen_setup(struct cdnsp_device *pdev) pdev->hci_version = HC_VERSION(pdev->hcc_params); pdev->hcc_params = readl(&pdev->cap_regs->hcc_params); + /* + * Override the APB timeout value to give the controller more time for + * enabling UTMI clock and synchronizing APB and UTMI clock domains. + * This fix is platform specific and is required to fixes issue with + * reading incorrect value from PORTSC register after resuming + * from L1 state. + */ + cdnsp_set_apb_timeout_value(pdev); + cdnsp_get_rev_cap(pdev); /* Make sure the Device Controller is halted. */ diff --git a/drivers/usb/cdns3/cdnsp-gadget.h b/drivers/usb/cdns3/cdnsp-gadget.h index 84887dfea763..87ac0cd113e7 100644 --- a/drivers/usb/cdns3/cdnsp-gadget.h +++ b/drivers/usb/cdns3/cdnsp-gadget.h @@ -520,6 +520,9 @@ struct cdnsp_rev_cap { #define REG_CHICKEN_BITS_2_OFFSET 0x48 #define CHICKEN_XDMA_2_TP_CACHE_DIS BIT(28) +#define REG_CHICKEN_BITS_3_OFFSET 0x4C +#define CHICKEN_APB_TIMEOUT_SET(p, val) (((p) & ~GENMASK(21, 0)) | (val)) + /* XBUF Extended Capability ID. */ #define XBUF_CAP_ID 0xCB #define XBUF_RX_TAG_MASK_0_OFFSET 0x1C diff --git a/drivers/usb/cdns3/cdnsp-pci.c b/drivers/usb/cdns3/cdnsp-pci.c index a51144504ff3..8c361b8394e9 100644 --- a/drivers/usb/cdns3/cdnsp-pci.c +++ b/drivers/usb/cdns3/cdnsp-pci.c @@ -28,6 +28,8 @@ #define PCI_DRIVER_NAME "cdns-pci-usbssp" #define PLAT_DRIVER_NAME "cdns-usbssp" +#define CHICKEN_APB_TIMEOUT_VALUE 0x1C20 + static struct pci_dev *cdnsp_get_second_fun(struct pci_dev *pdev) { /* @@ -139,6 +141,14 @@ static int cdnsp_pci_probe(struct pci_dev *pdev, cdnsp->otg_irq = pdev->irq; } + /* + * Cadence PCI based platform require some longer timeout for APB + * to fixes domain clock synchronization issue after resuming + * controller from L1 state. + */ + cdnsp->override_apb_timeout = CHICKEN_APB_TIMEOUT_VALUE; + pci_set_drvdata(pdev, cdnsp); + if (pci_is_enabled(func)) { cdnsp->dev = dev; cdnsp->gadget_init = cdnsp_gadget_init; @@ -148,8 +158,6 @@ static int cdnsp_pci_probe(struct pci_dev *pdev, goto free_cdnsp; } - pci_set_drvdata(pdev, cdnsp); - device_wakeup_enable(&pdev->dev); if (pci_dev_run_wake(pdev)) pm_runtime_put_noidle(&pdev->dev); diff --git a/drivers/usb/cdns3/core.h b/drivers/usb/cdns3/core.h index 921cccf1ca9d..801be9e61340 100644 --- a/drivers/usb/cdns3/core.h +++ b/drivers/usb/cdns3/core.h @@ -79,6 +79,8 @@ struct cdns3_platform_data { * @pdata: platform data from glue layer * @lock: spinlock structure * @xhci_plat_data: xhci private data structure pointer + * @override_apb_timeout: hold value of APB timeout. For value 0 the default + * value in CHICKEN_BITS_3 will be preserved. * @gadget_init: pointer to gadget initialization function */ struct cdns { @@ -117,6 +119,7 @@ struct cdns { struct cdns3_platform_data *pdata; spinlock_t lock; struct xhci_plat_priv *xhci_plat_data; + u32 override_apb_timeout; int (*gadget_init)(struct cdns *cdns); }; -- 2.43.0

1 week, 1 day

2
1
0 0

[to-be-updated] mm-contig_alloc-fix-alloc_contig_range-when-__gfp_comp-and-order-max_order.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/contig_alloc: fix alloc_contig_range when __GFP_COMP and order < MAX_ORDER has been removed from the -mm tree. Its filename was mm-contig_alloc-fix-alloc_contig_range-when-__gfp_comp-and-order-max_order.patch This patch was dropped because an updated version will be issued ------------------------------------------------------ From: Jinjiang Tu <tujinjiang(a)huawei.com> Subject: mm/contig_alloc: fix alloc_contig_range when __GFP_COMP and order < MAX_ORDER Date: Wed, 12 Mar 2025 16:47:05 +0800 When calling alloc_contig_range() with __GFP_COMP and the order of requested pfn range is pageblock_order, less than MAX_ORDER, I triggered WARNING as follows: PFN range: requested [2150105088, 2150105600), allocated [2150105088, 2150106112) WARNING: CPU: 3 PID: 580 at mm/page_alloc.c:6877 alloc_contig_range+0x280/0x340 alloc_contig_range() marks pageblocks of the requested pfn range to be isolated, migrate these pages if they are in use and will be freed to MIGRATE_ISOLATED freelist. Suppose two alloc_contig_range() calls at the same time and the requested pfn range are [0x80280000, 0x80280200) and [0x80280200, 0x80280400) respectively. Suppose the two memory range are in use, then alloc_contig_range() will migrate and free these pages to MIGRATE_ISOLATED freelist. __free_one_page() will merge MIGRATE_ISOLATE buddy to larger buddy, resulting in a MAX_ORDER buddy. Finally, find_large_buddy() in alloc_contig_range() returns a MAX_ORDER buddy and results in WARNING. To fix it, call free_contig_range() to free the excess pfn range. Link: https://lkml.kernel.org/r/20250312084705.2938220-1-tujinjiang@huawei.com Fixes: e98337d11bbd ("mm/contig_alloc: support __GFP_COMP") Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> Cc: David Hildenbrand <david(a)redhat.com> Cc: Kefeng Wang <wangkefeng.wang(a)huawei.com> Cc: Nanyong Sun <sunnanyong(a)huawei.com> Cc: Yu Zhao <yuzhao(a)google.com> Cc: Zi Yan <ziy(a)nvidia.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/page_alloc.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) --- a/mm/page_alloc.c~mm-contig_alloc-fix-alloc_contig_range-when-__gfp_comp-and-order-max_order +++ a/mm/page_alloc.c @@ -6786,7 +6786,8 @@ int alloc_contig_range_noprof(unsigned l goto done; } - if (!(gfp_mask & __GFP_COMP)) { + if (!(gfp_mask & __GFP_COMP) || + (is_power_of_2(end - start) && ilog2(end - start) < MAX_PAGE_ORDER)) { split_free_pages(cc.freepages, gfp_mask); /* Free head and tail (if any) */ @@ -6794,7 +6795,15 @@ int alloc_contig_range_noprof(unsigned l free_contig_range(outer_start, start - outer_start); if (end != outer_end) free_contig_range(end, outer_end - end); - } else if (start == outer_start && end == outer_end && is_power_of_2(end - start)) { + + outer_start = start; + outer_end = end; + + if (!(gfp_mask & __GFP_COMP)) + goto done; + } + + if (start == outer_start && end == outer_end && is_power_of_2(end - start)) { struct page *head = pfn_to_page(start); int order = ilog2(end - start); _ Patches currently in -mm which might be from tujinjiang(a)huawei.com are

1 week, 1 day

1
0
0 0

Re: Patch "wifi: mac80211: Update skb's control block key in ieee80211_tx_dequeue()" has been added to the 6.14-stable tree

by Remi Pommarel

Hello, On Sun, Apr 20, 2025 at 11:00:53AM -0400, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > wifi: mac80211: Update skb's control block key in ieee80211_tx_dequeue() > > to the 6.14-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > wifi-mac80211-update-skb-s-control-block-key-in-ieee.patch > and it can be found in the queue-6.14 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > Not sure this patch should go to stable. @Johannes haven't you revert it in your tree ? Thanks, -- Remi > > > commit 9209089b629b7c29ae393cded89e77c169f18dfb > Author: Remi Pommarel <repk(a)triplefau.lt> > Date: Mon Mar 24 17:28:20 2025 +0100 > > wifi: mac80211: Update skb's control block key in ieee80211_tx_dequeue() > > [ Upstream commit a104042e2bf6528199adb6ca901efe7b60c2c27f ] > > The ieee80211 skb control block key (set when skb was queued) could have > been removed before ieee80211_tx_dequeue() call. ieee80211_tx_dequeue() > already called ieee80211_tx_h_select_key() to get the current key, but > the latter do not update the key in skb control block in case it is > NULL. Because some drivers actually use this key in their TX callbacks > (e.g. ath1{1,2}k_mac_op_tx()) this could lead to the use after free > below: > > BUG: KASAN: slab-use-after-free in ath11k_mac_op_tx+0x590/0x61c > Read of size 4 at addr ffffff803083c248 by task kworker/u16:4/1440 > > CPU: 3 UID: 0 PID: 1440 Comm: kworker/u16:4 Not tainted 6.13.0-ge128f627f404 #2 > Hardware name: HW (DT) > Workqueue: bat_events batadv_send_outstanding_bcast_packet > Call trace: > show_stack+0x14/0x1c (C) > dump_stack_lvl+0x58/0x74 > print_report+0x164/0x4c0 > kasan_report+0xac/0xe8 > __asan_report_load4_noabort+0x1c/0x24 > ath11k_mac_op_tx+0x590/0x61c > ieee80211_handle_wake_tx_queue+0x12c/0x1c8 > ieee80211_queue_skb+0xdcc/0x1b4c > ieee80211_tx+0x1ec/0x2bc > ieee80211_xmit+0x224/0x324 > __ieee80211_subif_start_xmit+0x85c/0xcf8 > ieee80211_subif_start_xmit+0xc0/0xec4 > dev_hard_start_xmit+0xf4/0x28c > __dev_queue_xmit+0x6ac/0x318c > batadv_send_skb_packet+0x38c/0x4b0 > batadv_send_outstanding_bcast_packet+0x110/0x328 > process_one_work+0x578/0xc10 > worker_thread+0x4bc/0xc7c > kthread+0x2f8/0x380 > ret_from_fork+0x10/0x20 > > Allocated by task 1906: > kasan_save_stack+0x28/0x4c > kasan_save_track+0x1c/0x40 > kasan_save_alloc_info+0x3c/0x4c > __kasan_kmalloc+0xac/0xb0 > __kmalloc_noprof+0x1b4/0x380 > ieee80211_key_alloc+0x3c/0xb64 > ieee80211_add_key+0x1b4/0x71c > nl80211_new_key+0x2b4/0x5d8 > genl_family_rcv_msg_doit+0x198/0x240 > <...> > > Freed by task 1494: > kasan_save_stack+0x28/0x4c > kasan_save_track+0x1c/0x40 > kasan_save_free_info+0x48/0x94 > __kasan_slab_free+0x48/0x60 > kfree+0xc8/0x31c > kfree_sensitive+0x70/0x80 > ieee80211_key_free_common+0x10c/0x174 > ieee80211_free_keys+0x188/0x46c > ieee80211_stop_mesh+0x70/0x2cc > ieee80211_leave_mesh+0x1c/0x60 > cfg80211_leave_mesh+0xe0/0x280 > cfg80211_leave+0x1e0/0x244 > <...> > > Reset SKB control block key before calling ieee80211_tx_h_select_key() > to avoid that. > > Fixes: bb42f2d13ffc ("mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue") > Signed-off-by: Remi Pommarel <repk(a)triplefau.lt> > Link: https://patch.msgid.link/06aa507b853ca385ceded81c18b0a6dd0f081bc8.174283338… > Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c > index a24636bda6793..0c6214f12ea39 100644 > --- a/net/mac80211/tx.c > +++ b/net/mac80211/tx.c > @@ -3893,6 +3893,7 @@ struct sk_buff *ieee80211_tx_dequeue(struct ieee80211_hw *hw, > * The key can be removed while the packet was queued, so need to call > * this here to get the current key. > */ > + info->control.hw_key = NULL; > r = ieee80211_tx_h_select_key(&tx); > if (r != TX_CONTINUE) { > ieee80211_free_txskb(&local->hw, skb);

1 week, 1 day

2
1
0 0

[PATCH v3 1/3] iio: frequency: Use SLEEP bit instead of RESET to disable output

by Gabriel Shahrouzi

According to the AD9832 datasheet (Table 10, D12 description), setting the RESET bit forces the phase accumulator to zero, which corresponds to a full-scale DC output, rather than disabling the output signal. The correct way to disable the output and enter a low-power state is to set the AD9832_SLEEP bit (Table 10, D13 description), which powers down the internal DAC current sources and disables internal clocks. Fixes: ea707584bac1 ("Staging: IIO: DDS: AD9832 / AD9835 driver") Cc: stable(a)vger.kernel.org Signed-off-by: Gabriel Shahrouzi <gshahrouzi(a)gmail.com> --- drivers/staging/iio/frequency/ad9832.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/iio/frequency/ad9832.c b/drivers/staging/iio/frequency/ad9832.c index db42810c7664b..0872ff4ec4896 100644 --- a/drivers/staging/iio/frequency/ad9832.c +++ b/drivers/staging/iio/frequency/ad9832.c @@ -232,7 +232,7 @@ static ssize_t ad9832_write(struct device *dev, struct device_attribute *attr, st->ctrl_src &= ~(AD9832_RESET | AD9832_SLEEP | AD9832_CLR); else - st->ctrl_src |= AD9832_RESET; + st->ctrl_src |= AD9832_SLEEP; st->data = cpu_to_be16((AD9832_CMD_SLEEPRESCLR << CMD_SHIFT) | st->ctrl_src); -- 2.43.0

1 week, 1 day

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror