summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-01-21perf: Fix refcount warning on event->mmap_count incrementWill Rosenberg
When calling refcount_inc(&event->mmap_count) inside perf_mmap_rb(), the following warning is triggered: refcount_t: addition on 0; use-after-free. WARNING: lib/refcount.c:25 PoC: struct perf_event_attr attr = {0}; int fd = syscall(__NR_perf_event_open, &attr, 0, -1, -1, 0); mmap(NULL, 0x3000, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); int victim = syscall(__NR_perf_event_open, &attr, 0, -1, fd, PERF_FLAG_FD_OUTPUT); mmap(NULL, 0x3000, PROT_READ | PROT_WRITE, MAP_SHARED, victim, 0); This occurs when creating a group member event with the flag PERF_FLAG_FD_OUTPUT. The group leader should be mmap-ed and then mmap-ing the event triggers the warning. Since the event has copied the output_event in perf_event_set_output(), event->rb is set. As a result, perf_mmap_rb() calls refcount_inc(&event->mmap_count) when event->mmap_count = 0. Disallow the case when event->mmap_count = 0. This also prevents two events from updating the same user_page. Fixes: 448f97fba901 ("perf: Convert mmap() refcounts to refcount_t") Suggested-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Will Rosenberg <whrosenb@asu.edu> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260119184956.801238-1-whrosenb@asu.edu
2026-01-21Merge tag 'tee-bus-callback-for-6.20' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee into soc/drivers TEE bus callback for 6.20 - Move from generic device_driver to TEE bus-specific callbacks - Add module_tee_client_driver() and registration helpers to reduce boilerplate - Convert several client drivers (TPM, KEYS, firmware, EFI, hwrng, and RTC) - Update documentation and fix kernel-doc warnings * tag 'tee-bus-callback-for-6.20' of git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee: tpm/tpm_ftpm_tee: Fix kdoc after function renames tpm/tpm_ftpm_tee: Make use of tee bus methods tpm/tpm_ftpm_tee: Make use of tee specific driver registration KEYS: trusted: Make use of tee bus methods KEYS: trusted: Migrate to use tee specific driver registration function firmware: tee_bnxt: Make use of tee bus methods firmware: tee_bnxt: Make use of module_tee_client_driver() firmware: arm_scmi: Make use of tee bus methods firmware: arm_scmi: optee: Make use of module_tee_client_driver() efi: stmm: Make use of tee bus methods efi: stmm: Make use of module_tee_client_driver() hwrng: optee - Make use of tee bus methods hwrng: optee - Make use of module_tee_client_driver() rtc: optee: Make use of tee bus methods rtc: optee: Migrate to use tee specific driver registration function tee: Adapt documentation to cover recent additions tee: Add probe, remove and shutdown bus callbacks to tee_client_driver tee: Add some helpers to reduce boilerplate for tee client drivers Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-01-21Merge tag 'optee-update-for-6.20' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee into soc/drivers OP-TEE update for 6.20 - A micro optimization by making a local array static const - Update OP-TEE mailing list as moderated - Update an outdated comment for cmd_alloc_suppl() * tag 'optee-update-for-6.20' of git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee: optee: make read-only array attr static const MAINTAINERS: Mark the OP-TEE mailing list moderated optee: update outdated comment Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-01-21Merge tag 'qcomtee-fixes-for-6.20' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee into soc/drivers QCOMTEE fixes for 6.20 Small cleanups for the qcomtee driver to align with recommended coding practices for the cleanup.h infrastructure. * tag 'qcomtee-fixes-for-6.20' of git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee: tee: qcomtee: user: Fix confusing cleanup.h syntax tee: qcomtee: mem: Fix confusing cleanup.h syntax tee: qcomtee: call: Fix confusing cleanup.h syntax Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-01-21Merge tag 'renesas-drivers-for-v6.20-tag2' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/drivers Renesas driver updates for v6.20 (take two) - Add and use for_each_of_imap_item() iterator, - Add support for the RZ/N1 GPIO Interrupt Multiplexer. * tag 'renesas-drivers-for-v6.20-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: soc: renesas: Add support for RZ/N1 GPIO Interrupt Multiplexer irqchip/renesas-rza1: Use for_each_of_imap_item iterator irqchip/ls-extirq: Use for_each_of_imap_item iterator of: unittest: Add a test case for for_each_of_imap_item iterator of/irq: Introduce for_each_of_imap_item Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-01-21Merge tag 'scmi-updates-7.0' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into soc/drivers Arm SCMI updates for v7.0 A set of cleanups, refactoring, and fixes to the Arm SCMI stack: 1. Rework protocol version negotiation by moving version discovery and downgrade handling into the SCMI core and performing negotiation early, before protocol initialization. Remove legacy per-protocol versioning logic now made redundant by centralized SCMI handling. 2. Increase the internal MAX_OPPS limit in the SCMI performance protocol to 64, allowing platforms with larger OPP tables to be fully supported. 3. Reduce duplicated boilerplate in pinctrl and related protocols by consolidating validation and lookup logic in protocol get info helpers. 4. Refactor reset protocol domain handling by introducing a shared lookup helper, ensuring consistent validation and error reporting. 5. Fix potential undefined behaviour by properly initializing pointers annotated with the __free attribute. * tag 'scmi-updates-7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: firmware: arm_scmi: Remove legacy protocol versioning logic firmware: arm_scmi: Rework protocol version negotiation logic firmware: arm_scmi: Increase performance MAX_OPPS limit to 64 firmware: arm_scmi: Move boiler plate code into the get info functions firmware: arm_scmi: Refactor reset domain handling firmware: arm_scmi: Fix uninitialized pointers with __free attr Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-01-21nvmet: fix race in nvmet_bio_done() leading to NULL pointer dereferenceMing Lei
There is a race condition in nvmet_bio_done() that can cause a NULL pointer dereference in blk_cgroup_bio_start(): 1. nvmet_bio_done() is called when a bio completes 2. nvmet_req_complete() is called, which invokes req->ops->queue_response(req) 3. The queue_response callback can re-queue and re-submit the same request 4. The re-submission reuses the same inline_bio from nvmet_req 5. Meanwhile, nvmet_req_bio_put() (called after nvmet_req_complete) invokes bio_uninit() for inline_bio, which sets bio->bi_blkg to NULL 6. The re-submitted bio enters submit_bio_noacct_nocheck() 7. blk_cgroup_bio_start() dereferences bio->bi_blkg, causing a crash: BUG: kernel NULL pointer dereference, address: 0000000000000028 #PF: supervisor read access in kernel mode RIP: 0010:blk_cgroup_bio_start+0x10/0xd0 Call Trace: submit_bio_noacct_nocheck+0x44/0x250 nvmet_bdev_execute_rw+0x254/0x370 [nvmet] process_one_work+0x193/0x3c0 worker_thread+0x281/0x3a0 Fix this by reordering nvmet_bio_done() to call nvmet_req_bio_put() BEFORE nvmet_req_complete(). This ensures the bio is cleaned up before the request can be re-submitted, preventing the race condition. Fixes: 190f4c2c863a ("nvmet: fix memory leak of bio integrity") Cc: Dmitry Bogdanov <d.bogdanov@yadro.com> Cc: stable@vger.kernel.org Cc: Guangwu Zhang <guazhang@redhat.com> Link: http://www.mail-archive.com/debian-kernel@lists.debian.org/msg146238.html Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-01-21Merge tag 'ffa-updates-7.0' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into soc/drivers Arm FF-A updates for v7.0 A small set of updates to the Arm FF-A driver: 1. Fix a correctness issue in NOTIFICATION_INFO_GET handling of 32-bit firmware responses, avoiding reads from undefined register bits. 2. Improve clarity and robustness of FF-A feature checks by tying them to explicit version requirements. 3. Ensure Rx/Tx buffers are unmapped on FF-A initialization failure to prevent resource leaks. * tag 'ffa-updates-7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: firmware: arm_ffa: Correct 32-bit response handling in NOTIFICATION_INFO_GET firmware: arm_ffa: Tie FF-A version checks to specific features firmware: arm_ffa: Unmap Rx/Tx buffers on init failure Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-01-21selftests/io_uring: support NO_SQARRAY in miniliburingPavel Begunkov
Add support for IORING_SETUP_NO_SQARRAY in miniliburing. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-01-21selftests/io_uring: add io_uring_queue_init_paramsPavel Begunkov
Add a ring init variant taking struct io_uring_params, which mimicks liburing API. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-01-21selftests/ublk: fix garbage output in foreground modeMing Lei
Initialize _evtfd to -1 in struct dev_ctx to prevent garbage output when running kublk in foreground mode. Without this, _evtfd is zero-initialized to 0 (stdin), and ublk_send_dev_event() writes binary data to stdin which appears as garbage on the terminal. Also fix debug message format string. Fixes: 6aecda00b7d1 ("selftests: ublk: add kernel selftests for ublk") Signed-off-by: Ming Lei <ming.lei@redhat.com> Reviewed-by: Caleb Sander Mateos <csander@purestorage.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-01-21selftests/ublk: fix error handling for starting deviceMing Lei
Fix error handling in ublk_start_daemon() when start_dev fails: 1. Call ublk_ctrl_stop_dev() to cancel inflight uring_cmd before cleanup. Without this, the device deletion may hang waiting for I/O completion that will never happen. 2. Add fail_start label so that pthread_join() is called on the error path. This ensures proper thread cleanup when startup fails. Fixes: 6aecda00b7d1 ("selftests: ublk: add kernel selftests for ublk") Signed-off-by: Ming Lei <ming.lei@redhat.com> Reviewed-by: Caleb Sander Mateos <csander@purestorage.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-01-21selftests/ublk: fix IO thread idle checkMing Lei
Include cmd_inflight in ublk_thread_is_done() check. Without this, the thread may exit before all FETCH commands are completed, which may cause device deletion to hang. Fixes: 6aecda00b7d1 ("selftests: ublk: add kernel selftests for ublk") Signed-off-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-01-21Revert "mmc: rtsx_pci: add quirk to disable MMC_CAP_AGGRESSIVE_PM for RTS525A"Greg Kroah-Hartman
This reverts commit 5f0bf80cc5e04d31eeb201683e0b477c24bd18e7. This was asked to be reverted as it is not the correct way to do this. Fixes: 5f0bf80cc5e0 ("mmc: rtsx_pci: add quirk to disable MMC_CAP_AGGRESSIVE_PM for RTS525A") Cc: Matthew Schwartz <matthew.schwartz@linux.dev> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-21Revert "mmc: rtsx: reset power state on suspend"Greg Kroah-Hartman
This reverts commit eac85fbd0867c25ac517f58fae401d65c627edff. This is not the correct change, so revert it for now. Fixes: eac85fbd0867 ("mmc: rtsx: reset power state on suspend") Cc: Matthew Schwartz <matthew.schwartz@linux.dev> Cc: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-21Revert "mmc: rtsx_pci_sdmmc: increase power-on settling delay to 5ms"Greg Kroah-Hartman
This reverts commit aced969e9bf3701dc75cfca57c78c031b7875b9d. It was determined that this was not the correct "fix", so should be reverted. Fixes: aced969e9bf3 ("mmc: rtsx_pci_sdmmc: increase power-on settling delay to 5ms") Cc: Matthew Schwartz <matthew.schwartz@linux.dev> Cc: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-21Merge tag 'renesas-drivers-for-v6.20-tag1' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/drivers Renesas driver updates for v6.20 - Enable Interrupt Controller (ICU) support on the RZ/N2H SoC. * tag 'renesas-drivers-for-v6.20-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: soc: renesas: Enable ICU support on RZ/N2H Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-01-21block: make the new blkzoned UAPI constants discoverableChristoph Hellwig
The Linux 6.19 merge window added the new BLKREPORTZONESV2 ioctl, and with it the new BLK_ZONE_REP_CACHED and BLK_ZONE_COND_ACTIVE constants. The two constants are defined as part of enums, which makes it very painful for userspace to discover if they are present in the installed system headers. Use the #define to the same name trick to make them trivially discoverable using CPP directives. Fixes: 0bf0e2e46668 ("block: track zone conditions") Fixes: b30ffcdc0c15 ("block: introduce BLKREPORTZONESV2 ioctl") Reported-by: Andrey Albershteyn <aalbersh@redhat.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-01-21ublk: fix ublksrv pid handling for pid namespacesSeamus Connor
When ublksrv runs inside a pid namespace, START/END_RECOVERY compared the stored init-ns tgid against the userspace pid (getpid vnr), so the check failed and control ops could not proceed. Compare against the caller’s init-ns tgid and store that value, then translate it back to the caller’s pid namespace when reporting GET_DEV_INFO so ublk list shows a sensible pid. Testing: start/recover in a pid namespace; `ublk list` shows reasonable pid values in init, child, and sibling namespaces. Fixes: c2c8089f325e ("ublk: validate ublk server pid") Signed-off-by: Seamus Connor <sconnor@purestorage.com> Reviewed-by: Caleb Sander Mateos <csander@purestorage.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-01-21drm/xe: Update wedged.mode only after successful reset policy changeLukasz Laguna
Previously, the driver's internal wedged.mode state was updated without verifying whether the corresponding engine reset policy update in GuC succeeded. This could leave the driver reporting a wedged.mode state that doesn't match the actual reset behavior programmed in GuC. With this change, the reset policy is updated first, and the driver's wedged.mode state is modified only if the policy update succeeds on all available GTs. This patch also introduces two functional improvements: - The policy is sent to GuC only when a change is required. An update is needed only when entering or leaving XE_WEDGED_MODE_UPON_ANY_HANG, because only in that case the reset policy changes. For example, switching between XE_WEDGED_MODE_UPON_CRITICAL_ERROR and XE_WEDGED_MODE_NEVER doesn't affect the reset policy, so there is no need to send the same value to GuC. - An inconsistent_reset flag is added to track cases where reset policy update succeeds only on a subset of GTs. If such inconsistency is detected, future wedged mode configuration will force a retry of the reset policy update to restore a consistent state across all GTs. Fixes: 6b8ef44cc0a9 ("drm/xe: Introduce the wedged_mode debugfs") Signed-off-by: Lukasz Laguna <lukasz.laguna@intel.com> Link: https://patch.msgid.link/20260107174741.29163-3-lukasz.laguna@intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit 0f13dead4e0385859f5c9c3625a19df116b389d3) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-01-21rust: block: mq: use pin_init::zeroed() for tag_setKe Sun
Replace unsafe core::mem::zeroed() with pin_init::zeroed() for blk_mq_tag_set initialization. Signed-off-by: Ke Sun <sunke@kylinos.cn> Acked-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20260120083824.477339-4-sunke@kylinos.cn Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-01-21rust: block: mq: use pin_init::zeroed() for queue_limitsKe Sun
Replace unsafe core::mem::zeroed() with pin_init::zeroed() for queue_limits initialization. Signed-off-by: Ke Sun <sunke@kylinos.cn> Acked-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20260120083824.477339-3-sunke@kylinos.cn Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-01-21drm/xe/migrate: fix job lock assertMatthew Auld
We are meant to be checking the user vm for the bind queue, but actually we are checking the migrate vm. For various reasons this is not currently firing but this will likely change in the future. Now that we have the user_vm attached to the bind queue, we can fix this by directly checking that here. Fixes: dba89840a920 ("drm/xe: Add GT TLB invalidation jobs") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Arvind Yadav <arvind.yadav@intel.com> Link: https://patch.msgid.link/20260120110609.77958-4-matthew.auld@intel.com (cherry picked from commit 9dd1048bca4fe2aa67c7a286bafb3947537adedb) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-01-21drm/xe/uapi: disallow bind queue sharingMatthew Auld
Currently this is very broken if someone attempts to create a bind queue and share it across multiple VMs. For example currently we assume it is safe to acquire the user VM lock to protect some of the bind queue state, but if allow sharing the bind queue with multiple VMs then this quickly breaks down. To fix this reject using a bind queue with any VM that is not the same VM that was originally passed when creating the bind queue. This a uAPI change, however this was more of an oversight on kernel side that we didn't reject this, and expectation is that userspace shouldn't be using bind queues in this way, so in theory this change should go unnoticed. Based on a patch from Matt Brost. v2 (Matt B): - Hold the vm lock over queue create, to ensure it can't be closed as we attach the user_vm to the queue. - Make sure we actually check for NULL user_vm in destruction path. v3: - Fix error path handling. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Reported-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Michal Mrozek <michal.mrozek@intel.com> Cc: Carl Zhang <carl.zhang@intel.com> Cc: <stable@vger.kernel.org> # v6.8+ Acked-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Arvind Yadav <arvind.yadav@intel.com> Acked-by: Michal Mrozek <michal.mrozek@intel.com> Link: https://patch.msgid.link/20260120110609.77958-3-matthew.auld@intel.com (cherry picked from commit 9dd08fdecc0c98d6516c2d2d1fa189c1332f8dab) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-01-21PCI: dwc: Remove duplicate dw_pcie_ep_hide_ext_capability() functionQiang Yu
Remove dw_pcie_ep_hide_ext_capability() and replace its usage with dw_pcie_remove_ext_capability(). Both functions serve the same purpose of hiding PCIe extended capabilities, but dw_pcie_remove_ext_capability() provides a cleaner API that doesn't require the caller to specify the previous capability ID. Suggested-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Niklas Cassel <cassel@kernel.org> Link: https://patch.msgid.link/20251224-remove_dw_pcie_ep_hide_ext_capability-v1-1-4302c9cdc316@oss.qualcomm.com
2026-01-21perf list: Don't write to const memoryArnaldo Carvalho de Melo
Something now detected on fedora 44, where strchr() returns const if it is passed a const pointer: util/print-events.c: In function 'print_sdt_events': util/print-events.c:89:29: error: initialization discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers] 89 | char *bid = strchr(sdt_name->s, '@'); | ^~~~~~ Fix it by using strchrnul() + strncmp() instead of temporarily scrubbing it with '\0'. Reviewed-by: Ian Rogers <irogers@google.com> Suggested-by: David Laight <david.laight.linux@gmail.com> Link: https://lore.kernel.org/r/20260121112536.27fd5d11@pumpkin Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2026-01-21perf list: Signal changing const memory is okArnaldo Carvalho de Melo
In this case its a temp list that is created just for listing events and will be deleted at the end, so just cast it to get rid of the compiler warning. Reviewed-by: Ian Rogers <irogers@google.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2026-01-21media: rkvdec: Add HEVC support for the VDPU383 variantDetlev Casanova
The VDPU383 decoder is used on the RK3576 SoC and has support for HEVC. This patch also moves some functions to a common rkvdec-hevc-common.c file and adds a specific scaling matrix flatten function. The fluster score for JCT-VC-HEVC_V1 is 146/147. Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-01-21media: rkvdec: Add HEVC support for the VDPU381 variantDetlev Casanova
The VDPU381 supports HEVC decoding up to 7680x4320@30fps. It could double that when using both decoder cores. It support YUV420 (8 and 10 bits) as well as AFBC (not implemented here) The fluster score is 146/147 for JCT-VC-HEVC_V1, tested on ROCK 5B. None of the other test suites works. Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock 5B Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-01-21media: rkvdec: Add H264 support for the VDPU383 variantDetlev Casanova
This variant is used on the RK3576 SoC. The moving vectors size requirements are slightly different so support for a colmv_size function per variant is added. Also, the link registers are used to start the decoder and read IRQ status. The fluster score is 128/135 for JVT-AVC_V1, with MPS_MW_A failing in addition to the usual ones. The other test suites are not supported yet. Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-01-21media: rkvdec: Add H264 support for the VDPU381 variantDetlev Casanova
This decoder variant is found in Rockchip RK3588 SoC family. Like for rkvdec on rk3399, it supports the NV12, NV15, NV16 and NV20 output formats and level up to 6.0. The maximum width and height have been significantly increased supporting up to 65520 pixels for both. Support for named register sections is added for this variant and future ones. Fluster score for JVT-AVC_V1 is 129/135. Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock 5B Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-01-21media: rkvdec: Disable multicore supportDetlev Casanova
Similarly to what is done in Hantro, avoid exposing equal video codecs to userspace. Equal video codecs allow scheduling work between the cores. For that kernel support is required, which does not yet exist. Until that is implemented, avoid exposing each core separately to userspace so that multicore can be added in the future without breaking userspace ABI. This currently applies only to RK3588 which has 2 equal VDPU381 decoders, but will be applied for all SoC supported by rkvdec that has multiple DTS nodes with the same compatible. Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-01-21media: rkvdec: Enable all clocks without naming themDetlev Casanova
For other variants, the clock names and number will differ. There is no need to keep track of the clock names in the driver so drop them to avoid having a list for each variant. Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock 5B Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-01-21media: rkvdec: Support per-variant interrupt handlerDetlev Casanova
Prepare for supporting different variants with different interrupt managers. To support other variants specific function type later, introduce the rkvdec_variant_ops struct. Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock 5B Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-01-21media: rkvdec: Add RCB and SRAM supportDetlev Casanova
The RCB (Rows and Cols Buffers) are a set of buffers used by other variations of the decoder to store temporary data. Those variation come with a dedicated SRAM area used to store those buffers for better performances. The buffer sizes are either the width or height of the frame being decoded multiplied by a documented factor and can be stored either in SRAM or RAM. A fallback to RAM is provided if the SRAM is full (e.g.: multiple streams are being decoded at the same time). To manage the different kind of allocation, an enum is added to the rkvdec_aux_buf struct to specify how the buffer was allocated, and so, how to free it. This commit is in preparation of other variants support. Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock 5B Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-01-21media: rkvdec: Add variant specific coded formats listDetlev Casanova
Prepare for adding new variants of the decoder and support specific formats and format ops per variant. This removes the need of capability flags for variants, so remove them. Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock 5B Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-01-21media: rkvdec: Move hevc functions to common fileDetlev Casanova
This is a preparation commit to add support for new variants of the decoder. The functions will later be shared with vdpu381 (rk3588) and vdpu383 (rk3576). Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock 5B Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-01-21media: rkvdec: Move h264 functions to common fileDetlev Casanova
This is a preparation commit to add support for new variants of the decoder. The functions will later be shared with vdpu381 (rk3588) and vdpu383 (rk3576). Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock 5B Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-01-21media: rkvdec: Use structs to represent the HW RPSDetlev Casanova
This is in preparation to add support for other variants of the decoder. Moving to struct representation is mainly to prepare for multicore support that is present in e.g. rk3588. Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock 5B Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-01-21media: rkvdec: Move cabac tables to their own source fileDetlev Casanova
This is in preparation to add support for new variants that will use the same tables. Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock 5B Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-01-21media: rkvdec: Switch to using structs instead of writelDetlev Casanova
In an effort to merge the rkvdec2 driver [1] with this one, switch from writel() calls to using structs to represent the register mappings. This is done in order to have all supported decoders use the same format in the future and ease reading of the code. Using structs also improves stability as the hardware is tested and validated downstream using a similar method. It was noticed, on decoders, that: - Some registers require to be writen in increasing order [2] - Some registers, even if unrelated, need to be written to their reset values (it was the case here for axi_ddr_[rw]data). Using structs can also help improving performance later when, e.g. multicore support is added on RK3588. Performance seems to be slightly improved, but at least, not made worse. Running fluster's JVT-AVC_V1 test suite with GStreamer on the Radxa ROCK PI 4 SE gives the following times: Before this patch: - --jobs 1: Ran 129/135 tests successfully in 77.167 secs - --jobs 6: Ran 129/135 tests successfully in 23.046 secs With this patch: - --jobs 1: Ran 129/135 tests successfully in 70.698 secs - --jobs 6: Ran 129/135 tests successfully in 22.917 secs This also shows that the fluster score hasn't changed. [1]: https://lore.kernel.org/all/20250325213303.826925-1-detlev.casanova@collabora.com/ [2]: https://lore.kernel.org/all/20200127143009.15677-5-andrzej.p@collabora.com/ Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock 5B Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-01-21media: visl: Add HEVC short and long term RPS setsDetlev Casanova
Log the recently added v4l2 controls to set HEVC short and long term RPS sets with 2 new ftrace entries. Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-01-21media: v4l2-ctrls: Add hevc_ext_sps_[ls]t_rps controlsDetlev Casanova
The vdpu381 decoder found on newer Rockchip SoC need the information from the long term and short term ref pic sets from the SPS. So far, it wasn't included in the v4l2 API, so add it with new dynamic sized controls. Each element of the hevc_ext_sps_lt_rps array contains the long term ref pic set at that index. Each element of the hevc_ext_sps_st_rps contains the short term ref pic set at that index, as the raw data. It is the role of the drivers to calculate the reference sets values. Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-01-21media: uapi: HEVC: Add v4l2_ctrl_hevc_ext_sps_[ls]t_rps controlsDetlev Casanova
Some hardware (e.g.: Rockchip's rk3588 hevc decoder) need to fully parse the slice header, which cannot be passed with the current controls. There is also no skip method similar as to what can be found in verisilicon HW. The SPS is therefore extended through these 2 new controls, providing the long and short term reference information from the slice header for HEVC decoding. These now controls are similar as what is passed in the Vulkan Video API with the StdVideoH265ShortTermRefPicSet and StdVideoH265LongTermRefPicsSps structures embedded in the SPS struct. Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-01-21media: verisilicon: AV1: Fix tile info buffer sizeBenjamin Gaignard
Each tile info is composed of: row_sb, col_sb, start_pos and end_pos (4 bytes each). So the total required memory is AV1_MAX_TILES * 16 bytes. Use the correct #define to allocate the buffer and avoid writing tile info in non-allocated memory. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> Fixes: 727a400686a2c ("media: verisilicon: Add Rockchip AV1 decoder") Cc: stable@vger.kernel.org Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-01-21ASoC: cs35l56: Add KUnit testing of cs35l56_set_fw_suffix()Richard Fitzgerald
Add a new KUnit test for testing the creation of firmware name qualifiers in the cs35l56 driver. The initial set of test cases are for cs35l56_set_fw_suffix(). Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20260121132243.1256019-6-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-21ASoC: cs-amp-lib: Add a Kconfig symbol for enabling test hooksRichard Fitzgerald
Add Kconfig symbol CONFIG_SND_SOC_CS_AMP_LIB_TEST_HOOKS to enable calling into functions that would normally abort because of missing EFI functionality. Before this the code paths were only enabled if the KUnit test for cs-amp-lib was enabled. This change allows KUnit tests for clients of cs-amp-lib to install redirection hooks in cs-amp-lib. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20260121132243.1256019-5-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-21ASoC: cs-amp-lib-test: Tests for reading SSIDExV2Richard Fitzgerald
Adds test cases for getting a Dell SSIDExV2 string by calling cs_amp_devm_get_vendor_specific_variant_id(). This is a fairly simple test harness, the redirected call to cs_amp_get_efi_variable() returns a test string to simulate reading a string from UEFI. The returned string should be the second field in the SSIDExV2 string (if valid). Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20260121132243.1256019-4-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-21ASoC: cs35l56: Use vendor-specific qualifier in firmware file searchRichard Fitzgerald
If cs_amp_devm_get_vendor_specific_variant_id() returns a string, use it as part of the firmware filename. If this firmware isn't found, fall back to the standard firmware name. This re-uses the fwf_suffix fallback mechanism that was introduced in commit e5d5b3aebdc8 ("ASoC: cs35l56: Use SoundWire address as alternate firmware suffix on L56 B0"). This is for handling vendors that use the same PCI SSID on systems with various audio hardware and have a custom vendor-specific way to identify the hardware variant. This is currently used on Dell laptops. Dell create a UEFI variable that indicates varations to the base hardware. This variance can be any part of the hardware (not necessarily affecting the audio). It would be impractical to publish many aliases for the same firmware files to match every possible variance to that base hardware. Hence the fallback to the standard firmware name. This allows alternate firmware files to be published only for variants that need it. For all other variants the fallback will load the firmware for the base SSID. This is not done for CS35L56 B0 because the fallback mechanism is already used for a different purpose for these parts. None of the products with the older L56 B0 silicon revision need the additional vendor-specific descriptor. For SoundWire the resulting firmware searches with a variant descriptor will be: 1. cs35l??-dsp1-misc-SSID-VARIANT-l?u?.wmfw 2. cs35l??-dsp1-misc-SSID-VARIANT.wmfw 3. cs35l??-dsp1-misc-SSID-VARIANT-l?u?.bin 4. cs35l??-dsp1-misc-SSID-VARIANT.bin If this doesn't find a wmfw and bin file it will then fallback to: 5. cs35l??-dsp1-misc-SSID-l?u?.wmfw 6. cs35l??-dsp1-misc-SSID.wmfw 7. cs35l??-dsp1-misc-SSID-l?u?.bin 8. cs35l??-dsp1-misc-SSID.bin With the typical published firmware names and qualifiers (a single wmfw but amp-specific bin file) this will load either: cs35l??-dsp1-misc-SSID-VARIANT.wmfw and cs35l??-dsp1-misc-SSID-VARIANT-l?u?.bin or cs35l??-dsp1-misc-SSID.wmfw and cs35l??-dsp1-misc-SSID-l?u?.bin For non-Soundwire (I2S/TDM) systems the searches and fallbacks are as above except that the "l?u?" component of the name is instead the ALSA name prefix, usually of the form "AMPn". Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20260121132243.1256019-3-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-21ASoC: cs-amp-lib: Support Dell SSIDExV2 UEFI variableRichard Fitzgerald
Add a function cs_amp_devm_get_vendor_specific_variant_id() to return a vendor-specific hardware identifier string (if there is one) and use it to fetch an identifier from Dell SSIDExV2 UEFI variable content. Dell use the same PCI SSID on multiple products that might have different audio hardware and thus need different firmware for the amplifier DSP. The SSIDExV2 string contains additional system identifiers, and the second field is a 2-character audio hardware identifier. There are older Dell models with Cirrus Logic amplifiers that have the SSIDExV2 UEFI variable but do not have the 2-character audio ID in the second field. The SSIDExV2 is ignored if the second field is not 2 characters. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20260121132243.1256019-2-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2026-05-09 23:42:28 +0000