summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2026-04-01io_uring/zcrx: use guards for lockingPavel Begunkov1-8/+7
Convert last several places using manual locking to guards to simplify the code. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Link: https://patch.msgid.link/eb4667cfaf88c559700f6399da9e434889f5b04a.1774261953.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-04-01io_uring/zcrx: add a struct for refill queuePavel Begunkov2-31/+37
Add a new structure that keeps the refill queue state. It's cleaner and will be useful once we introduce multiple refill queues. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Link: https://patch.msgid.link/4ce200da1ff0309c377293b949200f95f80be9ae.1774261953.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-04-01io_uring/zcrx: use better name for RQ regionPavel Begunkov2-5/+5
Rename "region" to "rq_region" to highlight that it's a refill queue region. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Link: https://patch.msgid.link/ac815790d2477a15826aecaa3d94f2a94ef507e6.1774261953.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-04-01io_uring/zcrx: implement device-less mode for zcrxPavel Begunkov3-16/+36
Allow creating a zcrx instance without attaching it to a net device. All data will be copied through the fallback path. The user is also expected to use ZCRX_CTRL_FLUSH_RQ to handle overflows as it normally should even with a netdev, but it becomes even more relevant as there will likely be no one to automatically pick up buffers. Apart from that, it follows the zcrx uapi for the I/O path, and is useful for testing, experimentation, and potentially for the copy receive path in the future if improved. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Link: https://patch.msgid.link/674f8ad679c5a0bc79d538352b3042cf0999596e.1774261953.git.asml.silence@gmail.com [axboe: fix spelling error in uapi header and commit message] Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-04-01io_uring/zcrx: extract netdev+area init into a helperPavel Begunkov1-29/+43
In preparation to following patches, add a function that is responsibly for looking up a netdev, creating an area, DMA mapping it and opening a queue. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Link: https://patch.msgid.link/88cb6f746ecb496a9030756125419df273d0b003.1774261953.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-04-01io_uring/zcrx: always dma map in advancePavel Begunkov1-29/+15
zcrx was originally establisihing dma mappings at a late stage when it was being bound to a page pool. Dma-buf couldn't work this way, so it's initialised during area creation. It's messy having them do it at different spots, just move everything to the area creation time. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Link: https://patch.msgid.link/334092a2cbdd4aabd7c025050aa99f05ace89bb5.1774261953.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-04-01io_uring/zcrx: fully clean area on error in io_import_umem()Pavel Begunkov1-6/+10
When accounting fails, io_import_umem() sets the page array, etc. and returns an error expecting that the error handling code will take care of the rest. To make the next patch simpler, only return a fully initialised areas from the function. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Link: https://patch.msgid.link/3a602b7fb347dbd4da6797ac49b52ea5dedb856d.1774261953.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-04-01io_uring/zcrx: return back two step unregistrationPavel Begunkov3-3/+51
There are reports where io_uring instance removal takes too long and an ifq reallocation by another zcrx instance fails. Split zcrx destruction into two steps similarly how it was before, first close the queue early but maintain zcrx alive, and then when all inflight requests are completed, drop the main zcrx reference. For extra protection, mark terminated zcrx instances in xarray and warn if we double put them. Cc: stable@vger.kernel.org # 6.19+ Link: https://github.com/axboe/liburing/issues/1550 Reported-by: Youngmin Choi <youngminchoi94@gmail.com> Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Link: https://patch.msgid.link/0ce21f0565ab4358668922a28a8a36922dfebf76.1774261953.git.asml.silence@gmail.com [axboe: NULL ifq before break inside scoped guard] Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-04-01reset: rzv2h-usb2phy: Add support for VBUS mux controller registrationTommaso Merciai2-0/+36
The RZ/V2H USB2 PHY requires control of the VBUS selection line (VBENCTL) through a mux controller described in the device tree as "mux-controller". This change adds support for registering the rzv2h-usb-vbenctl auxiliary driver during probe. This enables proper management of USB2.0 VBUS source selection on platforms using the RZ/V2H SoC. Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2026-04-01reset: rzv2h-usb2phy: Convert to regmap APITommaso Merciai2-54/+55
Replace raw MMIO accesses (readl/writel) with regmap_read() and regmap_multi_reg_write() via devm_regmap_init_mmio(). Drop the manual spinlock as regmap provides internal locking. Replace the custom rzv2h_usb2phy_regval struct with the standard reg_sequence, and encode assert/deassert sequences as reg_sequence arrays rather than individual scalar fields in the of_data descriptor. Use the reg_sequence .delay_us field to encode the 11 µs post-assert delay, replacing the explicit usleep_range(11, 20) call in rzv2h_usbphy_reset_assert(). Select REGMAP_MMIO in Kconfig. Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2026-04-01dt-bindings: reset: renesas,rzv2h-usb2phy: Document RZ/G3E USB2PHY resetTommaso Merciai1-1/+3
Document USB2PHY reset controller bindings for RZ/G3E ("R9A09G047") SoC. The RZ/G3E USB2PHY reset controller is functionally identical to the one found on the RZ/V2H(P), so no driver changes are needed. The existing "renesas,r9a09g057-usb2phy-reset" will be used as a fallback compatible for this IP. Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2026-04-01dt-bindings: reset: renesas,rzv2h-usb2phy: Add '#mux-state-cells' propertyTommaso Merciai1-0/+5
Add the '#mux-state-cells' property to support describing the USB VBUS_SEL multiplexer as a mux-controller in the Renesas RZ/V2H(P) USB2PHY binding. The mux-controller cannot be integrated into the parent USB2PHY node because the VBUS source selector is part of a separate hardware block, not the USB2PHY block itself. This is required to properly configure USB PHY power selection on RZ/V2H(P) and RZ/G3E SoCs. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2026-04-01Input: aw86927 - add support for Awinic AW86938Griffin Kroah-Hartman1-8/+44
Add support for the I2C-connected Awinic AW86938 LRA haptic controller. The AW86938 has a similar but slightly different register layout. In particular, the boost mode register values. The AW86938 also has some extra features that aren't implemented in this driver yet. Signed-off-by: Griffin Kroah-Hartman <griffin.kroah@fairphone.com> Link: https://patch.msgid.link/20260302-aw86938-driver-v4-3-92c865df9cca@fairphone.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-04-01dt-bindings: input: awinic,aw86927: Add Awinic AW86938Griffin Kroah-Hartman1-1/+6
Add bindings for the Awinic AW86938 haptic chip which can be found in smartphones. These two chips require a similar devicetree configuration, but have a register layout that's not 100% compatible. Still, because chip model is fully detectable via ID register, these chips can be documnented in the same file. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Griffin Kroah-Hartman <griffin.kroah@fairphone.com> Link: https://patch.msgid.link/20260302-aw86938-driver-v4-2-92c865df9cca@fairphone.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-04-01Input: aw86927 - respect vibration magnitude levelsGriffin Kroah-Hartman1-7/+7
Previously the gain value was hardcoded. Take the magnitude passed via the input API and configure the gain register accordingly. Signed-off-by: Griffin Kroah-Hartman <griffin.kroah@fairphone.com> Link: https://patch.msgid.link/20260302-aw86938-driver-v4-1-92c865df9cca@fairphone.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-04-01tools/nolibc/printf: Support negative variable width and precisionDavid Laight2-32/+41
For (eg) "%*.*s" treat a negative field width as a request to left align the output (the same as the '-' flag), and a negative precision to request the default precision. Set the default precision to -1 (not INT_MAX) and add explicit checks to the string handling for negative values (makes the tet unsigned). For numeric output check for 'precision >= 0' instead of testing _NOLIBC_PF_FLAGS_CONTAIN(flags, '.'). This needs an inverted test, some extra goto and removes an indentation. The changed conditionals fix printf("%0-#o", 0) - but '0' and '-' shouldn't both be specified. Signed-off-by: David Laight <david.laight.linux@gmail.com> Link: https://patch.msgid.link/20260323112247.3196-1-david.laight.linux@gmail.com Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
2026-04-01KVM: arm64: Destroy stage-2 page-table in kvm_arch_destroy_vm()Will Deacon1-0/+1
kvm_arch_destroy_vm() can be called on the kvm_create_vm() error path after we have failed to register the MMU notifiers for the new VM. In this case, we cannot rely on the MMU ->release() notifier to call kvm_arch_flush_shadow_all() and so the stage-2 page-table allocated in kvm_arch_init_vm() will be leaked. Explicitly destroy the stage-2 page-table in kvm_arch_destroy_vm(), so that we clean up after kvm_arch_destroy_vm() without relying on the MMU notifiers. Link: https://sashiko.dev/#/patchset/20260327140039.21228-1-will%40kernel.org?patch=12265 Signed-off-by: Will Deacon <will@kernel.org> Link: https://patch.msgid.link/20260327192758.21739-3-will@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: Don't leave mmu->pgt dangling on kvm_init_stage2_mmu() errorWill Deacon1-0/+1
If kvm_init_stage2_mmu() fails to allocate 'mmu->last_vcpu_ran', it destroys the newly allocated stage-2 page-table before returning ENOMEM. Unfortunately, it also leaves a dangling pointer in 'mmu->pgt' which points at the freed 'kvm_pgtable' structure. This is likely to confuse the kvm_vcpu_init_nested() failure path which can double-free the structure if it finds it via kvm_free_stage2_pgd(). Ensure that the dangling 'mmu->pgt' pointer is cleared when returning an error from kvm_init_stage2_mmu(). Link: https://sashiko.dev/#/patchset/20260327140039.21228-1-will%40kernel.org?patch=12265 Signed-off-by: Will Deacon <will@kernel.org> Link: https://patch.msgid.link/20260327192758.21739-2-will@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: Prevent the host from using an smc with imm16 != 0Sebastian Ene1-0/+7
The ARM Service Calling Convention (SMCCC) specifies that the function identifier and parameters should be passed in registers, leaving the 16-bit immediate field un-handled in pKVM when an SMC instruction is trapped. Since the HVC is a private interface between EL2 and the host, enforce the host kernel running under pKVM to use an immediate value of 0 only when using SMCs to make it clear for non-compliant software talking to Trustzone that we only use SMCCC. Signed-off-by: Sebastian Ene <sebastianene@google.com> Reviewed-by: Vincent Donnefort <vdonnefort@google.com> Link: https://patch.msgid.link/20260330105441.3226904-1-sebastianene@google.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01timens: Use task_lock guard in timens_get*()Thomas Weißschuh1-16/+14
Simplify the logic in timens_get*() by converting the task_lock usage to a guard(). Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260330-timens-cleanup-v1-4-936e91c9dd30@linutronix.de
2026-04-01timens: Use mutex guard in proc_timens_set_offset()Thomas Weißschuh1-11/+5
Simplify the logic in proc_timens_set_offset() by converting the mutex usage to a guard(). Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260330-timens-cleanup-v1-3-936e91c9dd30@linutronix.de
2026-04-01timens: Simplify some calls to put_time_ns()Thomas Weißschuh1-18/+11
Use the new __free() based cleanup helpers to simplify some functions. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260330-timens-cleanup-v1-2-936e91c9dd30@linutronix.de
2026-04-01timens: Add a __free() wrapper for put_time_ns()Thomas Weißschuh1-0/+3
The wrapper will be used to simplify cleanups of 'struct time_namespace'. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260330-timens-cleanup-v1-1-936e91c9dd30@linutronix.de
2026-04-01tools/testing/cxl: Test dax_hmem takeover of CXL regionsDan Williams7-0/+173
When platform firmware is committed to publishing EFI_CONVENTIONAL_MEMORY in the memory map, but CXL fails to assemble the region, dax_hmem can attempt to attach a dax device to the memory range. Take advantage of the new ability to support multiple "hmem_platform" devices, and to enable regression testing of several scenarios: * CXL correctly assembles a region, check dax_hmem fails to attach dax * CXL fails to assemble a region, check dax_hmem successfully attaches dax * Check that loading the dax_cxl driver loads the dax_hmem driver * Attempt to race cxl_mock_mem async probe vs dax_hmem probe flushing. Check that both positive and negative cases. Signed-off-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Tested-by: Alison Schofield <alison.schofield@intel.com> Link: https://patch.msgid.link/20260327052821.440749-10-dan.j.williams@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-04-01tools/testing/cxl: Simulate auto-assembly failureDan Williams1-0/+9
Add a cxl_test module option to skip setting up one of the members of the default auto-assembled region. This simulates a device failing between firmware setup and OS boot, or region configuration interrupted by an event like kexec. Signed-off-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Link: https://patch.msgid.link/20260327052821.440749-9-dan.j.williams@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-04-01dax/hmem: Parent dax_hmem devicesDan Williams1-0/+1
For test purposes it is useful to be able to determine which "hmem_platform" device is hosting a given sub-device. Register hmem devices underneath "hmem_platform". Signed-off-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Link: https://patch.msgid.link/20260327052821.440749-8-dan.j.williams@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-04-01dax/hmem: Fix singleton confusion between dax_hmem_work and hmem devicesDan Williams3-66/+85
dax_hmem (ab)uses a platform device to allow for a module to autoload in the presence of "Soft Reserved" resources. The dax_hmem driver had no dependencies on the "hmem_platform" device being a singleton until the recent "dax_hmem vs dax_cxl" takeover solution. Replace the layering violation of dax_hmem_work assuming that there will never be more than one "hmem_platform" device associated with a global work item with a dax_hmem local workqueue that can theoretically support any number of hmem_platform devices. Fixup the reference counting to only pin the device while it is live in the queue. Signed-off-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Link: https://patch.msgid.link/20260327052821.440749-7-dan.j.williams@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-04-01dax/hmem: Reduce visibility of dax_cxl coordination symbolsDan Williams2-2/+2
No other module or use case should be using dax_hmem_initial_probe or dax_hmem_flush_work(). Limit their use to dax_hmem, and dax_cxl respectively. Signed-off-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Link: https://patch.msgid.link/20260327052821.440749-6-dan.j.williams@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-04-01cxl/region: Constify cxl_region_resource_contains()Dan Williams3-8/+9
The call to cxl_region_resource_contains() in hmem_register_cxl_device() need not cast away 'const'. The problem is the usage of the bus_for_each_dev() API which does not mark its @data parameter as 'const'. Switch to bus_find_device() which does take 'const' @data, fixup cxl_region_resource_contains() and its caller. Signed-off-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Link: https://patch.msgid.link/20260327052821.440749-5-dan.j.williams@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-04-01cxl/region: Limit visibility of cxl_region_contains_resource()Dan Williams4-18/+7
The dax_hmem dependency on cxl_region_contains_resource() is a one-off special case. It is not suitable for other use cases. Move the definition to the other CONFIG_CXL_REGION guarded definitions in drivers/cxl/cxl.h and include that by a relative path include. This matches what drivers/dax/cxl.c does for its limited private usage of CXL core symbols. Reduce the symbol export visibility from global to just dax_hmem, to further clarify its applicability. Signed-off-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Link: https://patch.msgid.link/20260327052821.440749-4-dan.j.williams@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-04-01dax/cxl: Fix HMEM dependenciesDan Williams1-2/+4
The expectation is that DEV_DAX_HMEM=y should be disallowed if any of CXL_ACPI, or CXL_PCI are set =m. Also DEV_DAX_CXL=y should be disallowed if DEV_DAX_HMEM=m. Use "$config || !$config" syntax for each dependency. Otherwise, the invalid DEV_DAX_HMEM=m && DEV_DAX_CXL=y configuration is allowed. Lastly, dax_hmem depends on the availability of the cxl_region_contains_resource() symbol published by the cxl_core.ko module. So, also prevent DEV_DAX_HMEM from being built-in when the cxl_core module is not built-in. Signed-off-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Link: https://patch.msgid.link/20260327052821.440749-3-dan.j.williams@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-04-01cxl/region: Fix use-after-free from auto assembly failureDan Williams2-3/+57
The following crash signature results from region destruction while an endpoint decoder is staged, but not fully attached. [ dj: Moved bus_find_device( to next line. ] Signed-off-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Link: https://patch.msgid.link/20260327052821.440749-2-dan.j.williams@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-04-01drm/msm: Use of_get_available_child_by_name()Biju Das1-2/+2
Simplify zap_shader_load_mdt() by using of_get_available_child_by_name(). Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Patchwork: https://patchwork.freedesktop.org/patch/635020/ Link: https://lore.kernel.org/r/20250201155830.39366-1-biju.das.jz@bp.renesas.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-04-01dt-bindings: display/msm: move DSI PHY bindings to phy/ subdirDmitry Baryshkov6-11/+11
Historically DSI PHY bindings landed to the display/msm subdir, however they describe PHYs and as such they should be in the phy/ subdir. Follow the example of other Qualcomm display-related PHYs (HDMI, eDP) and move bindings for the Qualcomm DSI PHYs to the correct subdir. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Acked-by: Vinod Koul <vkoul@kernel.org> Patchwork: https://patchwork.freedesktop.org/patch/709008/ Link: https://lore.kernel.org/r/20260305-msm-dsi-phy-v1-1-0a99ac665995@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-04-01drm/msm/dpu: eliza: Use Eliza-specific CWB arrayKrzysztof Kozlowski1-1/+1
The driver references CWB array from SM8650, but should use the Eliza specific, which has different register space sizes. This should not have noticeable impact on function but is indeed confusing, since the Eliza table is used for .cwb_count. Fixes: 0eb707bbc7fc ("drm/msm/dpu: Add support for Eliza SoC") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/715623/ Link: https://lore.kernel.org/r/20260331161156.211623-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-04-01drm/msm/dp: remove debugging prints with internal struct phy stateVladimir Oltean1-18/+0
These do not provide much value, and will become hard to maintain once the Generic PHY framework starts hiding the contents of struct phy from consumers. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/714986/ Link: https://lore.kernel.org/r/20260327184706.1600329-16-vladimir.oltean@nxp.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-04-01drm/msm/dpu: drop INTF_0 on MSM8953Dmitry Baryshkov1-7/+0
There is no INTF_0 on MSM8953. Currently catalog lists dummy INTF_NONE entry for it. Drop it from the catalog. Fixes: 7a6109ce1c2c ("drm/msm/dpu: Add support for MSM8953") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/713990/ Link: https://lore.kernel.org/r/20260325-drop-8953-intf-v1-1-d80e214a1a75@oss.qualcomm.com
2026-04-01drm/msm/dpu: correct DP MST interface configurationDmitry Baryshkov16-31/+28
Due to historical reasons we ended up with dummy values being specified for MST-related interfaces some of them had INTF_NONE, others had non-existing DP controller indices. Those workarounds are no longer necessary. Fix types and indices for all DP-MST related INTF instances. The only exception is INTF_3 on SC8180X, which has unique design. It can be used either with INTF_0 / DP0 or with INTF_4 / DP1. This interface is left with the dummy value until somebody implements necessary bits for that platform. Co-developed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/713988/ Link: https://lore.kernel.org/r/20260325-fix-dp-mst-interfaces-v1-1-186d1de3fa1b@oss.qualcomm.com
2026-04-01drm/msm/mdp5: drop workarounds specific to MDP5 1.0Dmitry Baryshkov1-7/+1
With support for MSM8974v1 being removed from the driver, there is no need to keep workarounds specific to that particular MDP5 revision. Drop them, slightly simplifying the logic. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/713918/ Link: https://lore.kernel.org/r/20260325-mdp5-further-drop-mdp1-0-v1-1-5ccee47fd1aa@oss.qualcomm.com
2026-04-01drm/msm/mdp5: drop single flush supportDmitry Baryshkov2-91/+0
Support for using a single CTL for flushing both interfaces was not in use since the MDP5 driver dropped support for dual DSI configurations in the commit df3c7899946c ("drm/msm/mdp5: drop split display support"). Having the MDP 3.x support migrated to the DPU driver the single CTL flush is applicable to the platforms suspproted by the MDP5 driver. Drop it alltogether. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/713916/ Link: https://lore.kernel.org/r/20260325-mdp5-drop-single-flush-v1-1-862a38b4d2ec@oss.qualcomm.com
2026-04-01hwmon: (asus-ec-sensors) Fix T_Sensor for PRIME X670E-PRO WIFICorey Hickey1-1/+6
On the Asus PRIME X670E-PRO WIFI, the driver reports a constant value of zero for T_Sensor. On this board, the register for T_Sensor is at a different address, as found by experimentation and confirmed by comparison to an independent temperature reading. * sensor disconnected: -62.0°C * ambient temperature: +22.0°C * held between fingers: +30.0°C Introduce SENSOR_TEMP_T_SENSOR_ALT1 to support the PRIME X670E-PRO WIFI without causing a regression for other 600-series boards Fixes: e0444758dd1b ("hwmon: (asus-ec-sensors) add PRIME X670E-PRO WIFI") Signed-off-by: Corey Hickey <bugfood-c@fatooh.org> Link: https://lore.kernel.org/r/20260331215414.368785-1-bugfood-ml@fatooh.org [groeck: Fixed typo, updated Fixes: reference] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-04-01KVM: arm64: set_id_regs: Allow GICv3 support to be set at runtimeMarc Zyngier1-7/+45
set_id_regs creates a GIC3 guest when possible, and then proceeds to write the ID registers as if they were not affected by the presence of a GIC. As it turns out, ID_AA64PFR1_EL1 is the proof of the contrary. KVM now makes a point in exposing the GIC support to the guest, no matter what userspace says (userspace such as QEMU is known to write silly things at times). Accommodate for this level of nonsense by teaching set_id_regs about fields that are mutable, and only compare registers that have been re-sanitised first. Reported-by: Mark Brown <broonie@kernel.org> Link: https://patch.msgid.link/20260401103611.357092-17-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: Don't advertises GICv3 in ID_PFR1_EL1 if AArch32 isn't supportedMarc Zyngier1-1/+2
Although the AArch32 ID regs are architecturally UNKNOWN when AArch32 isn't supported at any EL, KVM makes a point in making them RAZ. Therefore, advertising GICv3 in ID_PFR1_EL1 must be gated on AArch32 being supported at least at EL0. Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Fixes: a258a383b9177 ("KVM: arm64: gic-v5: Sanitize ID_AA64PFR2_EL1.GCIE") Reported-by: Mark Brown <broonie@kernel.org> Tested-by: Mark Brown <broonie@kernel.org> Link: https://patch.msgid.link/20260401103611.357092-16-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: Correctly plumb ID_AA64PFR2_EL1 into pkvm idreg handlingMarc Zyngier1-1/+1
While we now compute ID_AA64PFR2_EL1 to a glorious 0, we never use that data and instead return the 0 that corresponds to an allocated idreg. Not a big deal, but we might as well be consistent. Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Fixes: 5aefaf11f9af5 ("KVM: arm64: gic: Hide GICv5 for protected guests") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Link: https://patch.msgid.link/20260401103611.357092-15-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: Move GICv5 timer PPI validation into timer_irqs_are_valid()Marc Zyngier1-7/+4
Userspace can set the timer PPI numbers way before a GIC has been created, leading to odd behaviours on GICv5 as we'd accept non architectural PPI numbers. Move the v5 check into timer_irqs_are_valid(), which aligns the behaviour with the pre-v5 GICs, and is also guaranteed to run only once a GIC has been configured. Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Fixes: 9491c63b6cd7b ("KVM: arm64: gic-v5: Enlighten arch timer for GICv5") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Link: https://patch.msgid.link/20260401103611.357092-14-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: Remove evaluation of timer state in kvm_cpu_has_pending_timer()Marc Zyngier2-7/+3
The vgic-v5 code added some evaluations of the timers in a helper funtion (kvm_cpu_has_pending_timer()) that is called to determine whether the vcpu can wake-up. But looking at the timer there is wrong: - we want to see timers that are signalling an interrupt to the vcpu, and not just that have a pending interrupt - we already have kvm_arch_vcpu_runnable() that evaluates the state of interrupts - kvm_cpu_has_pending_timer() really is about WFIT, as the timeout does not generate an interrupt, and is therefore distinct from the point above As a consequence, revert these changes and teach vgic_v5_has_pending_ppi() about checking for pending HW interrupts instead. Fixes: 9491c63b6cd7b ("KVM: arm64: gic-v5: Enlighten arch timer for GICv5") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Link: https://patch.msgid.link/20260401103611.357092-13-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: Kill arch_timer_context::direct fieldMarc Zyngier2-9/+9
The newly introduced arch_timer_context::direct field is a bit pointless, as it is always set on timers that are... err... direct, while we already have a way to get to that by doing a get_map() operation. Additionally, this field is: - only set when get_map() is called - never cleared and the single point where it is actually checked doesn't call get_map() at all. At this stage, it is probably better to just kill it, and rely on get_map() to give us the correct information. Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Fixes: 9491c63b6cd7b ("KVM: arm64: gic-v5: Enlighten arch timer for GICv5") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Link: https://patch.msgid.link/20260401103611.357092-12-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: vgic-v5: Correctly set dist->ready once initialisedMarc Zyngier1-7/+11
kvm_vgic_map_resources() targetting a v5 model results in vgic->dist_ready never being set. This doesn't result in anything really bad, only some more heavy locking as we go and re-init something for no good reason. Rejig the code to correctly set the ready flag in all non-failing cases. Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Fixes: f4d37c7c35769 ("KVM: arm64: gic-v5: Create and initialise vgic_v5") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Link: https://patch.msgid.link/20260401103611.357092-11-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: vgic-v5: Make the effective priority mask a strict limitMarc Zyngier1-1/+1
The way the effective priority mask is compared to the priority of an interrupt to decide whether to wake-up or not, is slightly odd, and breaks at the limits. This could result in spurious wake-ups that are undesirable. Make the computed priority mask comparison a strict inequality, so that interrupts that have the same priority as the mask are not signalled. Fixes: 933e5288fa971 ("KVM: arm64: gic-v5: Check for pending PPIs") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Link: https://patch.msgid.link/20260401103611.357092-10-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-01KVM: arm64: vgic-v5: Cast vgic_apr to u32 to avoid undefined behavioursMarc Zyngier1-2/+3
Passing a u64 to __builtin_ctz() is odd, and requires some digging to figure out why this construct is indeed safe as long as the HW is correct. But it is much easier to make it clear to the compiler by casting the u64 into an intermediate u32, and be done with the UD. Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Fixes: 933e5288fa971 ("KVM: arm64: gic-v5: Check for pending PPIs") Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com Link: https://patch.msgid.link/20260401103611.357092-9-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-06-12 17:02:34 +0300