summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2026-05-22soc: ti: knav_dma: Remove unused DMA_PRIO_MASK macroNishanth Menon
DMA_PRIO_MASK (GENMASK(3, 0)) is defined alongside the other priority macros but is never referenced in the code. tx_priority and rx_priority are only ever assigned DMA_PRIO_DEFAULT (0) and are never sourced from device tree or user-controlled input, so no out-of-range value is possible. W=2 builds report: knav_dma.c:32:9: warning: macro is not used [-Wunused-macros] 32 | #define DMA_PRIO_MASK GENMASK(3, 0) Remove the dead macro. Reviewed-by: Sai Sree Kartheek Adivi <s-adivi@ti.com> Reviewed-by: Hari Prasath Gujulan Elango <gehariprasath@ti.com> Link: https://patch.msgid.link/20260512170623.3174416-9-nm@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2026-05-22soc: ti: knav_qmss_acc: Fix kernel-doc Return: tagNishanth Menon
Fix knav_init_acc_range() use of 'Return ...' instead of 'Return:' kernel-doc comment, which produces a warning with W=2: knav_qmss_acc.c:473: No description found for return value of 'knav_init_acc_range' Tested-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Sai Sree Kartheek Adivi <s-adivi@ti.com> Reviewed-by: Hari Prasath Gujulan Elango <gehariprasath@ti.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20260512170623.3174416-8-nm@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2026-05-22soc: ti: knav_qmss: Fix __iomem annotations and __be32 typeNishanth Menon
Fix several address-space and type annotation issues reported by sparse: - Change pdsp->command from 'void __iomem *' to 'u32 __iomem *' to match the other union members (acc_command, qos_command); adjust the offset in knav_queue_load_pdsp() from +0x18 to +0x6 to preserve the 24-byte offset. - Fix knav_queue_pdsp_wait() declaration: correct the parameter annotation from 'u32 * __iomem' (pointer-in-iomem-space) to 'u32 __iomem *' (pointer-to-iomem); use 'unsigned int' for the timeout parameter instead of bare 'unsigned'; fix the continuation- line alignment. - Use IOMEM_ERR_PTR() in knav_queue_map_reg() instead of ERR_PTR() when returning an error as void __iomem *. - Annotate the firmware data array as 'const __be32 *' instead of 'u32 *', as be32_to_cpu() requires __be32 input. Reviewed-by: Sai Sree Kartheek Adivi <s-adivi@ti.com> Reviewed-by: Hari Prasath Gujulan Elango <gehariprasath@ti.com> Link: https://patch.msgid.link/20260512170623.3174416-7-nm@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2026-05-22soc: ti: knav_qmss: Use %pe to print PTR_ERR()Nishanth Menon
Coccinelle (scripts/coccinelle/misc/ptr_err_to_pe.cocci) flags the dev_err() call in knav_pool_create(): knav_qmss_queue.c:789:9-16: WARNING: Consider using %pe to print PTR_ERR() Replace the %ld / PTR_ERR() pair with %pe and pass the error pointer directly to also print the symbolic error name. Reviewed-by: Sai Sree Kartheek Adivi <s-adivi@ti.com> Reviewed-by: Hari Prasath Gujulan Elango <gehariprasath@ti.com> Link: https://patch.msgid.link/20260512170623.3174416-6-nm@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2026-05-22soc: ti: knav_qmss: Fix kernel-doc Return: tagsNishanth Menon
Fix functions that use inline 'Returns ...' instead of 'Return:' kernel-doc comments, producing warnings with W=2: knav_qmss_queue.c:524: No description found for return value of 'knav_queue_open' Tested-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Sai Sree Kartheek Adivi <s-adivi@ti.com> Reviewed-by: Hari Prasath Gujulan Elango <gehariprasath@ti.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20260512170623.3174416-5-nm@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2026-05-22soc: ti: knav_qmss: Inline lockdep condition in for_each_handle_rcuNishanth Menon
knav_dev_lock_held() is a single-use wrapper around lockdep_is_held(&knav_dev_lock), used only as the lockdep condition in for_each_handle_rcu. When CONFIG_PROVE_RCU_LIST is disabled, list_for_each_entry_rcu() elides the condition argument entirely, causing clang to report the macro as unused with W=2: knav_qmss_queue.c:30:9: warning: macro is not used [-Wunused-macros] 30 | #define knav_dev_lock_held() \ Remove the intermediate macro and open-code lockdep_is_held() directly in the for_each_handle_rcu definition. Reviewed-by: Andrew Davis <afd@ti.com> Reviewed-by: Sai Sree Kartheek Adivi <s-adivi@ti.com> Reviewed-by: Hari Prasath Gujulan Elango <gehariprasath@ti.com> Link: https://patch.msgid.link/20260512170623.3174416-4-nm@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2026-05-22soc: ti: knav_qmss: Rename global kdev to knav_qdev to fix -WshadowNishanth Menon
Building with W=2 (clang, LLVM=1) produces 22 -Wshadow warnings in knav_qmss_queue.c because the file-scoped singleton 'kdev' is shadowed by a parameter of the same name in 21 internal functions and one local variable, e.g.: knav_qmss_queue.c:194:49: warning: declaration shadows a variable in the global scope [-Wshadow] 194 | knav_queue_match_id_to_inst(struct knav_device *kdev, unsigned id) Rename the global singleton from kdev to knav_qdev rather than renaming all ~21 function parameters, as this requires fewer changes and leaves function signatures, struct field accesses, and header macros in knav_qmss.h untouched. Reviewed-by: Sai Sree Kartheek Adivi <s-adivi@ti.com> Reviewed-by: Hari Prasath Gujulan Elango <gehariprasath@ti.com> Link: https://patch.msgid.link/20260512170623.3174416-3-nm@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2026-05-22soc: ti: knav_qmss: Remove remaining redundant ENOMEM printksNishanth Menon
Commit 168d2fb78055 ("soc: ti: knav_qmss: Remove ENOMEM printks") removed redundant dev_err() calls after allocation failures in knav_queue_setup_regions, knav_queue_init_qmgrs and knav_queue_init_pdsps, but missed three further instances in knav_pool_create, knav_queue_setup_region and knav_setup_queue_range. Remove the missed instances. Reviewed-by: Sai Sree Kartheek Adivi <s-adivi@ti.com> Reviewed-by: Hari Prasath Gujulan Elango <gehariprasath@ti.com> Link: https://patch.msgid.link/20260512170623.3174416-2-nm@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2026-05-22cpufreq: intel_pstate: Sync policy->cur during CPU offlineFushuai Wang
When a CPU goes offline with HWP disabled, intel_pstate_set_min_pstate() sets the MSR_IA32_PERF_CTL to minimum frequency to prevent SMT siblings from being restricted. However, the policy->cur value was not updated, leaving it at the previous value. When the CPU comes back online, governor->limits() checks if target_freq equals policy->cur and skips the frequency adjustment if they match. Since policy->cur still holds the previous value, the governor does not call cpufreq_driver->target to update MSR_IA32_PERF_CTL. Fix this by synchronizing policy->cur with the hardware state when setting minimum pstate during CPU offline. Fixes: bb18008f8086 ("intel_pstate: Set core to min P state during core offline") Cc: stable@vger.kernel.org # 3.15+ Suggested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Fushuai Wang <wangfushuai@baidu.com> [ rjw: Subject refinement ] Link: https://patch.msgid.link/20260520032119.30615-1-fushuai.wang@linux.dev Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-05-22Revert "accel/amdxdna: Support read-only user-pointer BO mappings"Lizhi Hou
This reverts commit f649e63d4a6423eda8eb208638849fd6396aedd7. The read-only feature requires further consideration. Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Link: https://patch.msgid.link/20260521162930.1451042-1-lizhi.hou@amd.com
2026-05-22vfio/pci: Use a private flag to prevent power state change with VFsRaghavendra Rao Ananta
The current implementation uses pci_num_vf() while holding the memory_lock to prevent changing the power state of a PF when VFs are enabled. This creates a lockdep circular dependency warning because memory_lock is held during device probing. [ 286.997167] ====================================================== [ 287.003363] WARNING: possible circular locking dependency detected [ 287.009562] 7.0.0-dbg-DEV #3 Tainted: G S [ 287.015074] ------------------------------------------------------ [ 287.021270] vfio_pci_sriov_/18636 is trying to acquire lock: [ 287.026942] ff45bea2294d4968 (&vdev->memory_lock){+.+.}-{4:4}, at: vfio_pci_core_runtime_resume+0x1f/0xa0 [ 287.036530] [ 287.036530] but task is already holding lock: [ 287.042383] ff45bea3a96b8230 (&new_dev_set->lock){+.+.}-{4:4}, at: vfio_group_fops_unl_ioctl+0x44d/0x7b0 [ 287.051879] [ 287.051879] which lock already depends on the new lock. [ 287.051879] [ 287.060070] [ 287.060070] the existing dependency chain (in reverse order) is: [ 287.067568] [ 287.067568] -> #2 (&new_dev_set->lock){+.+.}-{4:4}: [ 287.073941] __mutex_lock+0x92/0xb80 [ 287.078058] vfio_assign_device_set+0x66/0x1b0 [ 287.083042] vfio_pci_core_register_device+0xd1/0x2a0 [ 287.088638] vfio_pci_probe+0xd2/0x100 [ 287.092933] local_pci_probe_callback+0x4d/0xa0 [ 287.098001] process_scheduled_works+0x2ca/0x680 [ 287.103158] worker_thread+0x1e8/0x2f0 [ 287.107452] kthread+0x10c/0x140 [ 287.111230] ret_from_fork+0x18e/0x360 [ 287.115519] ret_from_fork_asm+0x1a/0x30 [ 287.119983] [ 287.119983] -> #1 ((work_completion)(&arg.work)){+.+.}-{0:0}: [ 287.127219] __flush_work+0x345/0x490 [ 287.131429] pci_device_probe+0x2e3/0x490 [ 287.135979] really_probe+0x1f9/0x4e0 [ 287.140180] __driver_probe_device+0x77/0x100 [ 287.145079] driver_probe_device+0x1e/0x110 [ 287.149803] __device_attach_driver+0xe3/0x170 [ 287.154789] bus_for_each_drv+0x125/0x150 [ 287.159346] __device_attach+0xca/0x1a0 [ 287.163720] device_initial_probe+0x34/0x50 [ 287.168445] pci_bus_add_device+0x6e/0x90 [ 287.172995] pci_iov_add_virtfn+0x3c9/0x3e0 [ 287.177719] sriov_add_vfs+0x2c/0x60 [ 287.181838] sriov_enable+0x306/0x4a0 [ 287.186038] vfio_pci_core_sriov_configure+0x184/0x220 [ 287.191715] sriov_numvfs_store+0xd9/0x1c0 [ 287.196351] kernfs_fop_write_iter+0x13f/0x1d0 [ 287.201338] vfs_write+0x2be/0x3b0 [ 287.205286] ksys_write+0x73/0x100 [ 287.209233] do_syscall_64+0x14d/0x750 [ 287.213529] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 287.219120] [ 287.219120] -> #0 (&vdev->memory_lock){+.+.}-{4:4}: [ 287.225491] __lock_acquire+0x14c6/0x2800 [ 287.230048] lock_acquire+0xd3/0x2f0 [ 287.234168] down_write+0x3a/0xc0 [ 287.238019] vfio_pci_core_runtime_resume+0x1f/0xa0 [ 287.243436] __rpm_callback+0x8c/0x310 [ 287.247730] rpm_resume+0x529/0x6f0 [ 287.251765] __pm_runtime_resume+0x68/0x90 [ 287.256402] vfio_pci_core_enable+0x44/0x310 [ 287.261216] vfio_pci_open_device+0x1c/0x80 [ 287.265947] vfio_df_open+0x10f/0x150 [ 287.270148] vfio_group_fops_unl_ioctl+0x4a4/0x7b0 [ 287.275476] __se_sys_ioctl+0x71/0xc0 [ 287.279679] do_syscall_64+0x14d/0x750 [ 287.283975] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 287.289559] [ 287.289559] other info that might help us debug this: [ 287.289559] [ 287.297582] Chain exists of: [ 287.297582] &vdev->memory_lock --> (work_completion)(&arg.work) --> &new_dev_set->lock [ 287.297582] [ 287.310023] Possible unsafe locking scenario: [ 287.310023] [ 287.315961] CPU0 CPU1 [ 287.320510] ---- ---- [ 287.325059] lock(&new_dev_set->lock); [ 287.328917] lock((work_completion)(&arg.work)); [ 287.336153] lock(&new_dev_set->lock); [ 287.342523] lock(&vdev->memory_lock); [ 287.346382] [ 287.346382] *** DEADLOCK *** [ 287.346382] [ 287.352315] 2 locks held by vfio_pci_sriov_/18636: [ 287.357125] #0: ff45bea208ed3e18 (&group->group_lock){+.+.}-{4:4}, at: vfio_group_fops_unl_ioctl+0x3e3/0x7b0 [ 287.367048] #1: ff45bea3a96b8230 (&new_dev_set->lock){+.+.}-{4:4}, at: vfio_group_fops_unl_ioctl+0x44d/0x7b0 [ 287.376976] [ 287.376976] stack backtrace: [ 287.381353] CPU: 191 UID: 0 PID: 18636 Comm: vfio_pci_sriov_ Tainted: G S 7.0.0-dbg-DEV #3 PREEMPTLAZY [ 287.381355] Tainted: [S]=CPU_OUT_OF_SPEC [ 287.381356] Call Trace: [ 287.381357] <TASK> [ 287.381358] dump_stack_lvl+0x54/0x70 [ 287.381361] print_circular_bug+0x2e1/0x300 [ 287.381363] check_noncircular+0xf9/0x120 [ 287.381364] ? __lock_acquire+0x5b4/0x2800 [ 287.381366] __lock_acquire+0x14c6/0x2800 [ 287.381368] ? pci_mmcfg_read+0x4f/0x220 [ 287.381370] ? pci_mmcfg_write+0x57/0x220 [ 287.381371] ? lock_acquire+0xd3/0x2f0 [ 287.381373] ? pci_mmcfg_write+0x57/0x220 [ 287.381374] ? lock_release+0xef/0x360 [ 287.381376] ? vfio_pci_core_runtime_resume+0x1f/0xa0 [ 287.381377] lock_acquire+0xd3/0x2f0 [ 287.381378] ? vfio_pci_core_runtime_resume+0x1f/0xa0 [ 287.381379] ? lock_is_held_type+0x76/0x100 [ 287.381382] down_write+0x3a/0xc0 [ 287.381382] ? vfio_pci_core_runtime_resume+0x1f/0xa0 [ 287.381383] vfio_pci_core_runtime_resume+0x1f/0xa0 [ 287.381384] ? __pfx_pci_pm_runtime_resume+0x10/0x10 [ 287.381385] __rpm_callback+0x8c/0x310 [ 287.381386] ? ktime_get_mono_fast_ns+0x3d/0xb0 [ 287.381389] ? __pfx_pci_pm_runtime_resume+0x10/0x10 [ 287.381390] rpm_resume+0x529/0x6f0 [ 287.381392] ? lock_is_held_type+0x76/0x100 [ 287.381394] __pm_runtime_resume+0x68/0x90 [ 287.381396] vfio_pci_core_enable+0x44/0x310 [ 287.381398] vfio_pci_open_device+0x1c/0x80 [ 287.381399] vfio_df_open+0x10f/0x150 [ 287.381401] vfio_group_fops_unl_ioctl+0x4a4/0x7b0 [ 287.381402] __se_sys_ioctl+0x71/0xc0 [ 287.381404] do_syscall_64+0x14d/0x750 [ 287.381405] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 287.381406] ? trace_irq_disable+0x25/0xd0 [ 287.381409] entry_SYSCALL_64_after_hwframe+0x77/0x7f Introduce a private flag 'sriov_active' in the vfio_pci_core_device struct. This allows the driver to track the SR-IOV power state requirement without relying on pci_num_vf() while holding the memory_lock. The lock is now only held to set the flag and ensure the device is in D0, after which pci_enable_sriov() can be called without the lock. Fixes: f4162eb1e2fc ("vfio/pci: Change the PF power state to D0 before enabling VFs") Cc: stable@vger.kernel.org Suggested-by: Jason Gunthorpe <jgg@ziepe.ca> Suggested-by: Alex Williamson <alex@shazbot.org> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com> Link: https://lore.kernel.org/r/20260514173449.3282188-1-rananta@google.com [promote bitfield to plain bool to avoid storage-unit races] Signed-off-by: Alex Williamson <alex@shazbot.org>
2026-05-22tun: free page on short-frame rejection in tun_xdp_one()Weiming Shi
tun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without freeing the page that vhost_net_build_xdp() allocated for it. tun_sendmsg() discards that -EINVAL and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page; each short frame in a batch leaks one page-frag chunk. A local process that can open /dev/net/tun and /dev/vhost-net can hit this path: it attaches a tun/tap device as the vhost-net backend and feeds TX descriptors whose length minus the virtio-net header is below ETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a tight submission loop exhausts host memory and triggers an OOM panic. Free the page before returning -EINVAL, matching the XDP-program error path in the same function. Fixes: 049584807f1d ("tun: add missing verification for short frame") Reported-by: Xiang Mei <xmei5@asu.edu> Signed-off-by: Weiming Shi <bestswngs@gmail.com> Reviewed-by: Dongli Zhang <dongli.zhang@oracle.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260520160020.375349-2-bestswngs@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-22Merge tag 'pm-7.1-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fixes from Rafael Wysocki: "These fix maximum frequency computation in the intel_pstate driver for two processor models, update its documentation and fix issues related to the dynamic EPP support (added during the current development cycle) in the amd-pstate driver: - Fix maximum frequency computation in the intel_pstate driver for Raptor Lake-E and Bartlett Lake that are SMP platforms derived from hybrid ones (Rafael Wysocki, Henry Tseng) - Fix the description of asymmetric packing with SMT in the intel_pstate driver documentation (Ricardo Neri) - Fix multiple amd-pstate driver issues related to dynamic EPP support added recently, including making it opt-in only (K Prateek Nayak, Mario Limonciello)" * tag 'pm-7.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: cpufreq/amd-pstate: Drop Kconfig option for dynamic EPP cpufreq: intel_pstate: Use HYBRID_SCALING_FACTOR_ADL for Bartlett Lake cpufreq: intel_pstate: Use correct scaling factor on Raptor Lake-E Documentation: intel_pstate: Fix description of asymmetric packing with SMT cpufreq/amd-pstate-ut: Drop policy reference before driver switch cpufreq/amd-pstate: Use "epp_default_dc" as default when dynamic_epp is disabled cpufreq/amd-pstate: Reorder notifier unregistration and floor perf reset cpufreq/amd-pstate: Allow writes to dynamic_epp when state isn't modified cpufreq/amd-pstate: Return -ENOMEM on failure to allocate profile_name cpufreq/amd-pstate: Grab "amd_pstate_driver_lock" when toggling dynamic_epp
2026-05-22drm/intel/display: Add support for pipe background color (v4)Maarten Lankhorst
Gen9 platforms allow CRTC's to be programmed with a background/canvas color below the programmable planes. Let's expose this as a property to allow userspace to program a desired value. This patch is based on earlier work by Chandra Konduru and Matt Roper. Between 2018 and now, intel/display has changed so much that another rewrite was necessary. v2: - Set initial background color (black) via proper helper function (Bob) - Fix debugfs output - General rebasing v3 (Maarten): - Rebase on top of recent changes. v4 (Maarten): - Complete rewrite based on the solution that went upstream, and on the new intel color management features. Cc: Chandra Konduru <chandra.konduru@intel.com> Cc: dri-devel@lists.freedesktop.org Co-developed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Link: https://patch.msgid.link/20260505200133.636584-2-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2026-05-22USB: serial: cypress_m8: fix memory corruption with small endpointJohan Hovold
Make sure that the interrupt-out endpoint max packet size is at least eight bytes to avoid user-controlled slab corruption or NULL-pointer dereference should a malicious device report a smaller size. Fixes: 3416eaa1f8f8 ("USB: cypress_m8: Packet format is separate from characteristic size") Cc: stable@vger.kernel.org # 2.6.26 Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2026-05-22Merge tag 'acpi-7.1-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI support fix from Rafael Wysocki: "Unbreak system wakeup on critical battery status in the ACPI battery driver inadvertently broken during the 7.0 development cycle" * tag 'acpi-7.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: battery: Fix system wakeup on critical battery status
2026-05-22ublk: factor out ublk_init_iod() helperCaleb Sander Mateos
The code for initializing struct ublksrv_io_desc on I/O dispatch is largely duplicated in 3 places. Commit 4d4a512a1f87 ("ublk: add PFN- based buffer matching in I/O path") added support to ublk_setup_iod() for matching request buffers against registered UBLK_F_SHMEM_ZC buffers, but missed adding it to ublk_setup_iod_zoned() for zoned requests. Move the duplicated logic to a new helper ublk_init_iod(). This way, zone appends can also benefit from avoiding the data copy. Signed-off-by: Caleb Sander Mateos <csander@purestorage.com> Reviewed-by: Ming Lei <tom.leiming@gmail.com> Link: https://patch.msgid.link/20260520203654.1413640-3-csander@purestorage.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-05-22ublk: move ublk_req_build_flags() earlierCaleb Sander Mateos
Move ublk_req_build_flags() above its callers so it doesn't need to be forward-declared. Signed-off-by: Caleb Sander Mateos <csander@purestorage.com> Reviewed-by: Ming Lei <tom.leiming@gmail.com> Link: https://patch.msgid.link/20260520203654.1413640-2-csander@purestorage.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-05-22ublk: optimize ublk_rq_has_data()Caleb Sander Mateos
ublk_rq_has_data() currently uses bio_has_data(), which involves 2 indirections and several branches. Use blk_rq_has_data() instead to save an indirection and NULL check. Signed-off-by: Caleb Sander Mateos <csander@purestorage.com> Reviewed-by: Ming Lei <tom.leiming@gmail.com> Link: https://patch.msgid.link/20260513211846.1956810-3-csander@purestorage.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-05-22drm/xe/rtp: Implement a structured parser for rule matchingGustavo Sousa
The current unwritten grammar for RTP rules is as follows: rules = disjunction; disjunction = conjunction, { "OR", conjunction }; conjunction = single_rule, { single_rule }; (* the AND operator is implicit *) single_rule = ? GRAPHICS_VERSION(...), MEDIA_VERSION(...), FUNC(...), etc ? While rule_matches() currently works for the grammar above, it doesn't easily resemble it. Let's replace it with an implementation that is structured in a way to resemble the grammar. Such a new implementation, although a bit more verbose, is arguably easier to reason about and to adapt to any extension we do to the grammer in the future. Also take this opportunity to update the kernel-doc for XE_RTP_RULES() to include the grammar, so that it is not unwritten anymore. v2: - Include the grammar in the code documentation. (Matt) Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Violet Monti <violet.monti@intel.com> Link: https://patch.msgid.link/20260522-rtp-rule-parser-v3-7-0c51039899f4@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-05-22drm/xe/rtp: Fully parse the rulesetGustavo Sousa
The function rule_matches() short-circuits evaluation of the implicit conjunctions (each substring of rules not containing OR) and the explicit disjunctions (implicit conjunctions joined by OR). In other words: - in a conjunction, once a rule evaluate to false, we skip to the next OR (if any) to evaluate the next conjunction; - in a disjunction, once a conjunction evaluates to true, we return true and skip evaluating all the remaining rules. While this behavior results in a correct logical value, due to how the "OR" short-circuiting is implemented, it has the side-effect that rule set does not get fully "parsed", allowing incomplete constructs like (rule1, OR) to evaluate to true when rule1 is true. We should treat such constructs as invalid and treat them the same way we do for stuff like (OR, rule1). As such, update rule_matches() to "parse" the whole rule set, and that while keeping the short-circuit aspect of evaluation. With that, we can fix the FIXME test cases that cover that behavior. v2: - Do not change short-circuit *evaluation* behavior. (Matt) Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Violet Monti <violet.monti@intel.com> Link: https://patch.msgid.link/20260522-rtp-rule-parser-v3-6-0c51039899f4@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-05-22drm/xe/rtp: Extract rule_match_item()Gustavo Sousa
The current logic in rule_matches() mixes individual rule matching with the logic necessary for handling OR operations. Let's simplify rule_matches() to focus on the latter by extracting individual rule matching into a separate function called rule_match_item(). Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260522-rtp-rule-parser-v3-5-0c51039899f4@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-05-22drm/xe/rtp: Do not break parsing when missing contextGustavo Sousa
With the current implementation, the RTP framework will cause parsing of the rule set to be interrupted if one rule requires a context item (gt or hwe) that is missing (i.e. when the value is NULL). This is arguably a semantic error instead of a syntactic one, meaning that RTP should not interrupt parsing the rules. With the current behavior, we would miss detecting other errors that could appear in the remaining rules and could also prevent valid rules joined by "OR" from being evaluated. Make sure that we do not stop parsing the rule set when detecting missing context and let's add rtp_rules_test_cases to reflect that. v2: - Add "missing-context" in the test case names to indicate that those are about rules that are missing the necessary context. (Matt) - Rebase: treat the new match type XE_RTP_MATCH_PLATFORM_STEP in the same way when the platform is missing step information. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> # v1 Link: https://patch.msgid.link/20260522-rtp-rule-parser-v3-4-0c51039899f4@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-05-22drm/xe/rtp: Don't short-circuit to false in or-yes caseGustavo Sousa
While RTP processing evaluates true on the "yes-or" case (i.e. a conjunction of rules that evaluate to true followed by an "OR" without the right hand operand), it does not on the "or-yes" one. Both cases are considered malformed and could be a result of someone dropping checks deemed not necessary anymore and forgetting to drop the superfluous "OR". Nevertheless, we should aim for consistency, and having the "or-yes" case also evaluating to true while also causing a warning seems reasonable. So let's do that. The "or-yes" pattern being evaluated to false comes from the fact that that we unconditionally short-circuit upon finding XE_RTP_MATCH_OR on the outer loop. We should only do that if the preceding conjunction of rules evaluated to true (meaning that rcount must be non-zero) and continue the evaluation otherwise. Do that and also add extra test cases to validate the short-circuiting behavior. Notice that some of the new test cases have a "FIXME" comment, which comes from the fact that we are unable to detect syntax errors after the short-circuit point. That is going to be fixed in a follow-up change. Link: https://lore.kernel.org/intel-xe/871pfw4lo9.fsf@intel.com/ Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Violet Monti <violet.monti@intel.com> Link: https://patch.msgid.link/20260522-rtp-rule-parser-v3-3-0c51039899f4@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-05-22drm/xe/rtp: Drop rule matching cases from rtp_to_sr_cases and rtp_casesGustavo Sousa
The kunit test cases for the RTP framework are currently separated into three groups: (1) rtp_rules_cases: Those to verify rule matching logic. (2) rtp_to_sr_cases: Those to verify generation of save/restore tables from RTP tables. (3) rtp_cases Those to verify processing of RTP tables without save/restore action associated, which are used for OOB workarounds. Today we have some cases in (2) and (3) that are actually meant to verify rule matching logic. Now that we have (1), let's cleanup (2) and (3) so that they become focused on their main objectives. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260522-rtp-rule-parser-v3-2-0c51039899f4@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-05-22drm/xe/rtp: Write kunit test cases specific for rule matchingGustavo Sousa
The kunit test cases for the RTP framework are currently separated into those that validate xe_rtp_process_to_sr() and those that validate xe_rtp_process(). In both of them, we also have mixed stuff to validate rule matching functionality, which should rather be done in a separate test case group. Let's create such a group, specific for validating rule matching, and also add an initial set of cases. In an upcoming change, we will do a cleanup of the other groups by migrating those cases intended for rule matching to this new group. v2: - s/no-yes-or-no-yes/no-yes-or-yes-no/ (Matt) - Drop leftover include of <kunit/test.h>. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260522-rtp-rule-parser-v3-1-0c51039899f4@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-05-22drm/msm/dpu: invert the order of UBWC checksDmitry Baryshkov
Unlike other drivers, the DPU driver checks for exact UBWC version, making it hard to add minor versions if necessary. Invert the order of UBWC checks, letting the DPU driver handle new minors transparently. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/726511/ Link: https://lore.kernel.org/r/20260520-ubwc-rework-v5-21-72f2749bc807@oss.qualcomm.com
2026-05-22drm/msm/dpu: drop ubwc_dec_versionDmitry Baryshkov
Stop using ubwc_dec_version (the version of the UBWC block in the display subsystem) for detecting the enablement of the UBWC. Use only ubwc_enc_version, the version of the UBWC which we are setting up for. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/726515/ Link: https://lore.kernel.org/r/20260520-ubwc-rework-v5-20-72f2749bc807@oss.qualcomm.com
2026-05-22drm/msm/mdss: use new helper to set amsbcDmitry Baryshkov
Use freshly defined helper instead of checking the UBWC version directly. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/726525/ Link: https://lore.kernel.org/r/20260520-ubwc-rework-v5-19-72f2749bc807@oss.qualcomm.com
2026-05-22drm/msm/adreno: use version ranges in A8xx UBWC codeDmitry Baryshkov
In order to simplify handling of UBWC minor revisions (like 3.1 or 4.3) use version ranges instead of a case switch. Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/726506/ Link: https://lore.kernel.org/r/20260520-ubwc-rework-v5-18-72f2749bc807@oss.qualcomm.com
2026-05-22drm/msm/adreno: use new helper to set amsbcDmitry Baryshkov
Use freshly defined helper instead of checking the UBWC version directly. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/726523/ Link: https://lore.kernel.org/r/20260520-ubwc-rework-v5-17-72f2749bc807@oss.qualcomm.com
2026-05-22drm/msm/adreno: set fp16compoptdis for UBWC 3.0 formatsDmitry Baryshkov
The fp16compoptdis bit should be set if the system targets UBWC 3.0 format in addition to UBWC 4.0. Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/726507/ Link: https://lore.kernel.org/r/20260520-ubwc-rework-v5-16-72f2749bc807@oss.qualcomm.com
2026-05-22drm/msm/adreno: write reserved UBWC-related bitsDmitry Baryshkov
On the latest A8xx Adreno chips several of the bits in the UBWC-related registers are now hardwired to 1. Currently the driver doesn't write them because there is no side-effect. In the preparation for the refactoring in the next patch, write '1' to those bits anyway. Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/726504/ Link: https://lore.kernel.org/r/20260520-ubwc-rework-v5-15-72f2749bc807@oss.qualcomm.com
2026-05-22drm/msm/mdss: use new helper to set ubwc_swizzleDmitry Baryshkov
Use freshly defined helper instead of using the raw value from the database. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/726516/ Link: https://lore.kernel.org/r/20260520-ubwc-rework-v5-14-72f2749bc807@oss.qualcomm.com
2026-05-22drm/msm/dpu: use new helper to set ubwc_swizzleDmitry Baryshkov
Use freshly defined helper instead of using the raw value from the database. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/726496/ Link: https://lore.kernel.org/r/20260520-ubwc-rework-v5-13-72f2749bc807@oss.qualcomm.com
2026-05-22drm/msm/adreno: use new helper to set ubwc_swizzleDmitry Baryshkov
Use freshly defined helper instead of using the raw value from the database. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/726498/ Link: https://lore.kernel.org/r/20260520-ubwc-rework-v5-12-72f2749bc807@oss.qualcomm.com
2026-05-22drm/msm/mdss: use new helper to set UBWC bank spreadingDmitry Baryshkov
Use freshly defined helper instead of hardcoding the checks in the driver. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/726501/ Link: https://lore.kernel.org/r/20260520-ubwc-rework-v5-11-72f2749bc807@oss.qualcomm.com
2026-05-22drm/msm/mdss: use new helper to set macrotile_modeDmitry Baryshkov
Use freshly defined helper instead of using the raw value from the database. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/726497/ Link: https://lore.kernel.org/r/20260520-ubwc-rework-v5-10-72f2749bc807@oss.qualcomm.com
2026-05-22drm/msm/adreno: use new helper to set macrotile_modeDmitry Baryshkov
Use freshly defined helper instead of using the raw value from the database. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/726493/ Link: https://lore.kernel.org/r/20260520-ubwc-rework-v5-9-72f2749bc807@oss.qualcomm.com
2026-05-22drm/msm/mdss: use new helper to set min_acc lengthDmitry Baryshkov
Use freshly defined helper instead of hardcoding the checks in the driver. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/726500/ Link: https://lore.kernel.org/r/20260520-ubwc-rework-v5-8-72f2749bc807@oss.qualcomm.com
2026-05-22drm/msm/adreno: use new helper to set min_acc lengthDmitry Baryshkov
Use freshly defined helper instead of hardcoding the checks in the driver. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/726495/ Link: https://lore.kernel.org/r/20260520-ubwc-rework-v5-7-72f2749bc807@oss.qualcomm.com
2026-05-22drm/msm/mdss: use qcom_ubwc_version_tag() helperDmitry Baryshkov
Use new helper defined to program UBWC version to the hardware. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/726487/ Link: https://lore.kernel.org/r/20260520-ubwc-rework-v5-6-72f2749bc807@oss.qualcomm.com
2026-05-22drm/msm/adreno: use qcom_ubwc_version_tag() helperDmitry Baryshkov
Use new helper defined to program UBWC version to the hardware. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/726485/ Link: https://lore.kernel.org/r/20260520-ubwc-rework-v5-5-72f2749bc807@oss.qualcomm.com
2026-05-22drm/msm/adreno: Trust the SSoT UBWC configKonrad Dybcio
Now that the highest_bank_bit value is retrieved from the running system and the global config has been part of the tree for a couple of releases, there is no reason to keep any hardcoded values inside the GPU driver. Get rid of them. Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/726488/ Link: https://lore.kernel.org/r/20260520-ubwc-rework-v5-4-72f2749bc807@oss.qualcomm.com
2026-05-22drm/msm/mdss: correct UBWC programming sequencesDmitry Baryshkov
The UBWC registers in the MDSS region are not dependent on the UBWC version (it is an invalid assumption we inherited from the vendor SDE driver). Instead they are dependent only on the MDSS core revision. Rework UBWC programming to follow MDSS revision and to use required (aka encoder) UBWC version instead of the ubwc_dec_version. Fixes: d68db6069a8e ("drm/msm/mdss: convert UBWC setup to use match data") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/723384/ Link: https://lore.kernel.org/r/20260507-ubwc-rework-v4-1-c19593d20c1d@oss.qualcomm.com
2026-05-22drm/msm/dpu: Add Milos supportLuca Weiss
Add definitions for the display hardware used on the Qualcomm Milos platform. Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/722323/ Link: https://lore.kernel.org/r/20260501-milos-mdss-v3-8-58bfc58c0e13@fairphone.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-05-22drm/msm: mdss: Add Milos supportLuca Weiss
Add support for MDSS on Milos. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Patchwork: https://patchwork.freedesktop.org/patch/722320/ Link: https://lore.kernel.org/r/20260501-milos-mdss-v3-7-58bfc58c0e13@fairphone.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-05-22drm/msm/dsi: add support for DSI-PHY on MilosLuca Weiss
Add DSI PHY support for the Milos platform. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Patchwork: https://patchwork.freedesktop.org/patch/722319/ Link: https://lore.kernel.org/r/20260501-milos-mdss-v3-6-58bfc58c0e13@fairphone.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-05-22Merge tag 's390-7.1-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Alexander Gordeev: - Fix PAI NNPA mismatch between counting and recording, where sampling reports twice the value - Fix loss of PAI counter increments during recording on systems with many CPUs under heavy load, while counting is not affected - On some supported machines, CHSC cannot access memory outside the DMA zone, causing CHSC command failures. Restore GFP_DMA flag when allocating memory for CHSC control blocks - Align the numbering scheme for higher-level topology structures like socket, book, drawer with other hardware identifiers e.g. in sysfs, procfs and tools like lscpu * tag 's390-7.1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/topology: Use zero-based numbering for containing entities s390/cio: Restore GFP_DMA for CHSC allocation s390/pai: Fix missing PAI counter increments under heavy load s390/pai: Disable duplicate read of kernel PAI counter value
2026-05-22platform/x86: bitland-mifs-wmi: add CONFIG_LEDS_CLASS dependencyArnd Bergmann
The newly added driver requires the LED classdev support and causes a link failure when that is disabled: x86_64-linux-ld: vmlinux.o: in function `bitland_mifs_wmi_probe': bitland-mifs-wmi.c:(.text+0xede02a): undefined reference to `devm_led_classdev_register_ext' Fixes: dc1ec4fa86b2 ("platform/x86: bitland-mifs-wmi: Add new Bitland MIFS WMI driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20260519202804.1339581-1-arnd@kernel.org Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-03 00:23:08 +0000