summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-02-19net/mlx5e: Fix deadlocks between devlink and netdev instance locksCosmin Ratiu
In the mentioned "Fixes" commit, various work tasks triggering devlink health reporter recovery were switched to use netdev_trylock to protect against concurrent tear down of the channels being recovered. But this had the side effect of introducing potential deadlocks because of incorrect lock ordering. The correct lock order is described by the init flow: probe_one -> mlx5_init_one (acquires devlink lock) -> mlx5_init_one_devl_locked -> mlx5_register_device -> mlx5_rescan_drivers_locked -...-> mlx5e_probe -> _mlx5e_probe -> register_netdev (acquires rtnl lock) -> register_netdevice (acquires netdev lock) => devlink lock -> rtnl lock -> netdev lock. But in the current recovery flow, the order is wrong: mlx5e_tx_err_cqe_work (acquires netdev lock) -> mlx5e_reporter_tx_err_cqe -> mlx5e_health_report -> devlink_health_report (acquires devlink lock => boom!) -> devlink_health_reporter_recover -> mlx5e_tx_reporter_recover -> mlx5e_tx_reporter_recover_from_ctx -> mlx5e_tx_reporter_err_cqe_recover The same pattern exists in: mlx5e_reporter_rx_timeout mlx5e_reporter_tx_ptpsq_unhealthy mlx5e_reporter_tx_timeout Fix these by moving the netdev_trylock calls from the work handlers lower in the call stack, in the respective recovery functions, where they are actually necessary. Fixes: 8f7b00307bf1 ("net/mlx5e: Convert mlx5 netdevs to instance locking") Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Jacob Keller <Jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260218072904.1764634-6-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-19net/mlx5e: MACsec, add ASO poll loop in macsec_aso_set_arm_eventGal Pressman
The macsec_aso_set_arm_event function calls mlx5_aso_poll_cq once without a retry loop. If the CQE is not immediately available after posting the WQE, the function fails unnecessarily. Use read_poll_timeout() to poll 3-10 usecs for CQE, consistent with other ASO polling code paths in the driver. Fixes: 739cfa34518e ("net/mlx5: Make ASO poll CQ usable in atomic context") Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Jianbo Liu <jianbol@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Jacob Keller <Jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260218072904.1764634-5-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-19net/mlx5: Fix misidentification of write combining CQE during poll loopGal Pressman
The write combining completion poll loop uses usleep_range() which can sleep much longer than requested due to scheduler latency. Under load, we witnessed a 20ms+ delay until the process was rescheduled, causing the jiffies based timeout to expire while the thread is sleeping. The original do-while loop structure (poll, sleep, check timeout) would exit without a final poll when waking after timeout, missing a CQE that arrived during sleep. Instead of the open-coded while loop, use the kernel's poll_timeout_us() which always performs an additional check after the sleep expiration, and is less error-prone. Note: poll_timeout_us() doesn't accept a sleep range, by passing 10 sleep_us the sleep range effectively changes from 2-10 to 3-10 usecs. Fixes: d98995b4bf98 ("net/mlx5: Reimplement write combining test") Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Jianbo Liu <jianbol@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Jacob Keller <Jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260218072904.1764634-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-19net/mlx5e: Fix misidentification of ASO CQE during poll loopGal Pressman
The ASO completion poll loop uses usleep_range() which can sleep much longer than requested due to scheduler latency. Under load, we witnessed a 20ms+ delay until the process was rescheduled, causing the jiffies based timeout to expire while the thread is sleeping. The original do-while loop structure (poll, sleep, check timeout) would exit without a final poll when waking after timeout, missing a CQE that arrived during sleep. Instead of the open-coded while loop, use the kernel's read_poll_timeout() which always performs an additional check after the sleep expiration, and is less error-prone. Note: read_poll_timeout() doesn't accept a sleep range, by passing 10 sleep_us the sleep range effectively changes from 2-10 to 3-10 usecs. Fixes: 739cfa34518e ("net/mlx5: Make ASO poll CQ usable in atomic context") Fixes: 7e3fce82d945 ("net/mlx5e: Overcome slow response for first macsec ASO WQE") Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Jianbo Liu <jianbol@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Jacob Keller <Jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260218072904.1764634-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-19net/mlx5: Fix multiport device check over light SFsShay Drory
Driver is using num_vhca_ports capability to distinguish between multiport master device and multiport slave device. num_vhca_ports is a capability the driver sets according to the MAX num_vhca_ports capability reported by FW. On the other hand, light SFs doesn't set the above capbility. This leads to wrong results whenever light SFs is checking whether he is a multiport master or slave. Therefore, use the MAX capability to distinguish between master and slave devices. Fixes: e71383fb9cd1 ("net/mlx5: Light probe local SFs") Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Jacob Keller <Jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260218072904.1764634-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-19bonding: alb: fix UAF in rlb_arp_recv during bond up/downHangbin Liu
The ALB RX path may access rx_hashtbl concurrently with bond teardown. During rapid bond up/down cycles, rlb_deinitialize() frees rx_hashtbl while RX handlers are still running, leading to a null pointer dereference detected by KASAN. However, the root cause is that rlb_arp_recv() can still be accessed after setting recv_probe to NULL, which is actually a use-after-free (UAF) issue. That is the reason for using the referenced commit in the Fixes tag. [ 214.174138] Oops: general protection fault, probably for non-canonical address 0xdffffc000000001d: 0000 [#1] SMP KASAN PTI [ 214.186478] KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef] [ 214.194933] CPU: 30 UID: 0 PID: 2375 Comm: ping Kdump: loaded Not tainted 6.19.0-rc8+ #2 PREEMPT(voluntary) [ 214.205907] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.14.0 01/14/2022 [ 214.214357] RIP: 0010:rlb_arp_recv+0x505/0xab0 [bonding] [ 214.220320] Code: 0f 85 2b 05 00 00 48 b8 00 00 00 00 00 fc ff df 40 0f b6 ed 48 c1 e5 06 49 03 ad 78 01 00 00 48 8d 7d 28 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 06 0f 8e 12 05 00 00 80 7d 28 00 0f 84 8c 00 [ 214.241280] RSP: 0018:ffffc900073d8870 EFLAGS: 00010206 [ 214.247116] RAX: dffffc0000000000 RBX: ffff888168556822 RCX: ffff88816855681e [ 214.255082] RDX: 000000000000001d RSI: dffffc0000000000 RDI: 00000000000000e8 [ 214.263048] RBP: 00000000000000c0 R08: 0000000000000002 R09: ffffed11192021c8 [ 214.271013] R10: ffff8888c9010e43 R11: 0000000000000001 R12: 1ffff92000e7b119 [ 214.278978] R13: ffff8888c9010e00 R14: ffff888168556822 R15: ffff888168556810 [ 214.286943] FS: 00007f85d2d9cb80(0000) GS:ffff88886ccb3000(0000) knlGS:0000000000000000 [ 214.295966] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 214.302380] CR2: 00007f0d047b5e34 CR3: 00000008a1c2e002 CR4: 00000000001726f0 [ 214.310347] Call Trace: [ 214.313070] <IRQ> [ 214.315318] ? __pfx_rlb_arp_recv+0x10/0x10 [bonding] [ 214.320975] bond_handle_frame+0x166/0xb60 [bonding] [ 214.326537] ? __pfx_bond_handle_frame+0x10/0x10 [bonding] [ 214.332680] __netif_receive_skb_core.constprop.0+0x576/0x2710 [ 214.339199] ? __pfx_arp_process+0x10/0x10 [ 214.343775] ? sched_balance_find_src_group+0x98/0x630 [ 214.349513] ? __pfx___netif_receive_skb_core.constprop.0+0x10/0x10 [ 214.356513] ? arp_rcv+0x307/0x690 [ 214.360311] ? __pfx_arp_rcv+0x10/0x10 [ 214.364499] ? __lock_acquire+0x58c/0xbd0 [ 214.368975] __netif_receive_skb_one_core+0xae/0x1b0 [ 214.374518] ? __pfx___netif_receive_skb_one_core+0x10/0x10 [ 214.380743] ? lock_acquire+0x10b/0x140 [ 214.385026] process_backlog+0x3f1/0x13a0 [ 214.389502] ? process_backlog+0x3aa/0x13a0 [ 214.394174] __napi_poll.constprop.0+0x9f/0x370 [ 214.399233] net_rx_action+0x8c1/0xe60 [ 214.403423] ? __pfx_net_rx_action+0x10/0x10 [ 214.408193] ? lock_acquire.part.0+0xbd/0x260 [ 214.413058] ? sched_clock_cpu+0x6c/0x540 [ 214.417540] ? mark_held_locks+0x40/0x70 [ 214.421920] handle_softirqs+0x1fd/0x860 [ 214.426302] ? __pfx_handle_softirqs+0x10/0x10 [ 214.431264] ? __neigh_event_send+0x2d6/0xf50 [ 214.436131] do_softirq+0xb1/0xf0 [ 214.439830] </IRQ> The issue is reproducible by repeatedly running ip link set bond0 up/down while receiving ARP messages, where rlb_arp_recv() can race with rlb_deinitialize() and dereference a freed rx_hashtbl entry. Fix this by setting recv_probe to NULL and then calling synchronize_net() to wait for any concurrent RX processing to finish. This ensures that no RX handler can access rx_hashtbl after it is freed in bond_alb_deinitialize(). Reported-by: Liang Li <liali@redhat.com> Fixes: 3aba891dde38 ("bonding: move processing of recv handlers into handle_frame()") Reviewed-by: Nikolay Aleksandrov <nikolay@nvidia.com> Acked-by: Jay Vosburgh <jv@jvosburgh.net> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Link: https://patch.msgid.link/20260218060919.101574-1-liuhangbin@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-19bnge: fix reserving resources from FWVikas Gupta
HWRM_FUNC_CFG is used to reserve resources, whereas HWRM_FUNC_QCFG is intended for querying resource information from the firmware. Since __bnge_hwrm_reserve_pf_rings() reserves resources for a specific PF, the command type should be HWRM_FUNC_CFG. Fixes: 627c67f038d2 ("bng_en: Add resource management support") Signed-off-by: Vikas Gupta <vikas.gupta@broadcom.com> Reviewed-by: Bhargava Chenna Marreddy <bhargava.marreddy@broadcom.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260218052755.4097468-1-vikas.gupta@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-02-19drm/amd/display: Remove unneeded DAC link encoder registerTimur Kristóf
Not needed anymore since we use the VBIOS function. Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Tested-by: Mauro Rossi <issor.oruam@gmail.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amd/display: Enable DAC in DCE link encoderTimur Kristóf
Ensure that the DAC output is enabled at the correct time by moving it to the DCE link encoder similarly to how digital outputs are enabled. This also removes the call to DAC1EncoderControl from the DCE HWSS, which always felt like it was a hacky solution. Fixes: 0fbe321a93ce ("drm/amd/display: Implement DCE analog link encoders (v2)") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Tested-by: Mauro Rossi <issor.oruam@gmail.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amd/display: Set CRTC source for DAC using registersTimur Kristóf
Apparently the VBIOS SelectCRTC_Source function overwrites a few registers (such as FMT_*) which DC writes in a different place, which can cause problems. Instead of using the SelectCRTC_Source function from the VBIOS, use the DAC_SOURCE_SELECT register directly, similarly to how it is done for digital link encoders. Fixes: 3be26d81b150 ("drm/amd/display: Support DAC in dce110_hwseq") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Tested-by: Mauro Rossi <issor.oruam@gmail.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amd/display: Initialize DAC in DCE link encoder using VBIOSTimur Kristóf
The VBIOS DAC1EncoderControl() function can initialize the DAC, by writing board-specific values to certain registers. Call this at link encoder hardware initialization time similarly to how the equivalent UNIPHYTransmitterControl initialization is done. This fixes DAC output on the Radeon HD 7790. Also remove the ENCODER_CONTROL_SETUP enum from the dac_encoder_control_prepare_params function which is actually not a supported operation for DAC encoders. Fixes: 0fbe321a93ce ("drm/amd/display: Implement DCE analog link encoders (v2)") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Tested-by: Mauro Rossi <issor.oruam@gmail.com> Suggested-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amd/display: Turn off DAC in DCE link encoder using VBIOSTimur Kristóf
Apparently, the VBIOS DAC1EncoderControl function is much more graceful about turning off the DAC. It writes various DAC registers in a specific sequence. Use that instead of just clearing the DAC_ENABLE register. Do this in just the dce110_link_encoder_disable_output function and remove it from the HWSS. Fixes: 0fbe321a93ce ("drm/amd/display: Implement DCE analog link encoders (v2)") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Tested-by: Mauro Rossi <issor.oruam@gmail.com> Suggested-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amd/display: Don't call find_analog_engine() twiceTimur Kristóf
The analog engine is already there in the link_analog_engine variable and assigned to enc_init_data.analog_engine already. I suspect this was a rebase mistake. Fixes: 436d0d22aa70 ("drm/amd/display: Pass proper DAC encoder ID to VBIOS") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Tested-by: Mauro Rossi <issor.oruam@gmail.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amdgpu: fix 4-level paging if GMC supports 57-bit VA v2Christian König
It turned that using 4 level page tables on GMC generations which support 57bit VAs actually doesn't work at all. Background is that the GMC actually can't switch between 4 and 5 levels, but rather just uses a subset of address space when less than 5 levels are selected. Philip already removed the automatically switch to 4levels, now fix it as well should it be enabled by module parameters. v2: fix AMDGPU_GMC_HOLE_MASK as well, fix off by one issue pointed out by Philip Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Philip Yang <philip.yang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amdgpu: keep vga memory on MacBooks with switchable graphicsAlex Deucher
On Intel MacBookPros with switchable graphics, when the iGPU is enabled, the address of VRAM gets put at 0 in the dGPU's virtual address space. This is non-standard and seems to cause issues with the cursor if it ends up at 0. We have the framework to reserve memory at 0 in the address space, so enable it here if the vram start address is 0. Reviewed-and-tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4302 Cc: stable@vger.kernel.org Cc: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amdgpu: Set atomics to true for xgmiHarish Kasiviswanathan
xgmi support atomics between links. Set them to true. This only set for GFX12 onwards to avoid regression on older generations v2: Use correct xgmi flag that indicates CPU connection Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amdkfd: Check for NULL return valuesAndrew Martin
This patch fixes issues when the code moves forward with a potential NULL pointer, without checking. Removed one redundant NULL check for a function parameter. This check is already done in the only caller. Signed-off-by: Andrew Martin <andrew.martin@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amd/display: Use same max plane scaling limits for all 64 bpp formatsMario Kleiner
The plane scaling hw seems to have the same min/max plane scaling limits for all 16 bpc / 64 bpp interleaved pixel color formats. Therefore add cases to amdgpu_dm_plane_get_min_max_dc_plane_scaling() for all the 16 bpc fixed-point / unorm formats to use the same .fp16 up/downscaling factor limits as used by the fp16 floating point formats. So far, 16 bpc unorm formats were not handled, and the default: path returned max/min factors for 32 bpp argb8888 formats, which were wrong and bigger than what many DCE / DCN hw generations could handle. The result sometimes was misscaling of framebuffers with DRM_FORMAT_XRGB16161616, DRM_FORMAT_ARGB16161616, DRM_FORMAT_XBGR16161616, DRM_FORMAT_ABGR16161616, leading to very wrong looking display, as tested on Polaris11 / DCE-11.2. So far this went unnoticed, because only few userspace clients used such 16 bpc unorm framebuffers, and those didn't use hw plane scaling, so they did not experience this issue. With upcoming Mesa 26 exposing 16 bpc unorm formats under both OpenGL and Vulkan under Wayland, and the upcoming GNOME 50 Mutter Wayland compositor allowing for direct scanout of these formats, the scaling hw will be used on these formats if possible for HiDPI display scaling, so it is important to use the correct hw scaling limits to avoid wrong display. Tested on AMD Polaris 11 / DCE 11.2 with upcoming Mesa 26 and GNOME 50 on HiDPI displays with scaling enabled. The mutter Wayland compositor now correctly falls back to scaling via desktop compositing instead of direct scanout, thereby avoiding wrong image display. For unscaled mode, it correctly uses direct scanout. Fixes: 580204038f5b ("drm/amd/display: Enable support for 16 bpc fixed-point framebuffers.") Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amdgpu: Set vmid0 PAGE_TABLE_DEPTH for GFX12.1Harish Kasiviswanathan
GFX12.1 uses 2 level gart table. Set the context register appropriately Signed-off-by: Feifei Xu <Feifei.Xu@amd.com> Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Reviewed-by: Mukul Joshi <mukul.joshi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amdkfd: Disable MQD queue priorityAndrew Martin
This solves a priority inversion issue, caused by the language runtime making high-priority queues wait for activity on lower-priority queues. Signed-off-by: Andrew Martin <andrew.martin@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amd/display: Remove conditional for shaper 3DLUT power-onAlex Hung
[Why] Shaper programming has high chance to fail on first time after power-on or reboot. This can be verified by running IGT's kms_colorop. [How] Always power on the shaper and 3DLUT before programming by removing the debug flag of low power mode. Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amd/display: Check return of shaper curve to HW formatAlex Hung
[Why & How] Check return of cm3_helper_translate_curve_to_hw_format. This is reported as a CHECKED_RETURN error by Coverity. Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amd/display: Correct logic check error for fastbootCharlene Liu
[Why] Fix fastboot broken in driver. This is caused by an open source backport change 7495962c. from the comment, the intended check is to disable fastboot for pre-DCN10. but the logic check is reversed, and causes fastboot to be disabled on all DCN10 and after. fastboot is for driver trying to pick up bios used hw setting and bypass reprogramming the hw if dc_validate_boot_timing() condition meets. Fixes: 7495962cbceb ("drm/amd/display: Disable fastboot on DCE 6 too") Cc: stable@vger.kernel.org Reviewed-by: Mario Limonciello <Mario.Limonciello@amd.com> Reviewed-by: Ovidiu Bunea <ovidiu.bunea@amd.com> Signed-off-by: Charlene Liu <Charlene.Liu@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amd/display: Skip eDP detection when no sinkSaidireddy Yenugu
[Why & How] When there is no eDP panel connected and during s0ix resume, unnecessary eDP power sequence and HPD happening, resulting in ~2 seconds delay. Fixed the issue by avoiding link detect for eDP connection with no sink in dm_resume. Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Saidireddy Yenugu <Saidireddy.Yenugu@amd.com> Co-developed-by: ThummarDip Kishorbhai <ThummarDip.Kishorbhai@amd.com> Signed-off-by: ThummarDip Kishorbhai <ThummarDip.Kishorbhai@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19Revert "drm/amd/display: Add Gfx Base Case For Linear Tiling Handling"Nicholas Carbones
This reverts commit 08a01ec306db ("drm/amd/display: Add Gfx Base Case For Linear Tiling Handling") Reason for revert: Got blank screen issues while doing PNP Reviewed-by: Joshua Aberback <joshua.aberback@amd.com> Signed-off-by: Nicholas Carbones <Nicholas.Carbones@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19Revert "drm/amd/display: Correct hubp GfxVersion verification"Nicholas Carbones
This reverts commit 3303aa64e7a6 ("drm/amd/display: Correct hubp GfxVersion verification") Reason for revert: Got blank screen issues while doing PNP Reviewed-by: Joshua Aberback <joshua.aberback@amd.com> Signed-off-by: Nicholas Carbones <Nicholas.Carbones@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19Revert "drm/amd/display: Add Handling for gfxversion DcGfxBase"Nicholas Carbones
This reverts commit 2e193f5b1b4f ("drm/amd/display: Add Handling for gfxversion DcGfxBase") Reason for revert: Cause some regressions Reviewed-by: Dillon Varone <dillon.varone@amd.com> Signed-off-by: Nicholas Carbones <Nicholas.Carbones@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amd/display: Migrate DCCG registers access from hwseq to dccg component.Bhuvanachandra Pinninti
[Why] Direct DCCG register access in hwseq layer was creating register conflicts. [How] Migrated DCCG registers from hwseq-dccg component. Reviewed-by: Martin Leung <Martin.Leung@amd.com> Signed-off-by: Bhuvanachandra Pinninti <BhuvanaChandra.Pinninti@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amd/display: Implementing ramless idle mouse triggerMuaaz Nisar
[Why & How] Adding mouse trigger in dc_stream to recover from low refresh rate idle state upon mouse movement without vsync interrupts. Reviewed-by: Aric Cyr <aric.cyr@amd.com> Signed-off-by: Muaaz Nisar <muaaz.nisar@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amd/display: Disable SR feature on eDP1 by defaultCharlene Liu
[Why & How] Disable SR feature on eDP1 by default. Reviewed-by: Wenjing Liu <wenjing.liu@amd.com> Signed-off-by: Charlene Liu <Charlene.Liu@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19drm/amd/display: Expose functions of other dcn useDmytro Laktyushkin
[Why & HOw] Expose some functions for later dcns to reuse Reviewed-by: Charlene Liu <charlene.liu@amd.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Dmytro Laktyushkin <dmytro.laktyushkin@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-02-19eth: fbnic: Advertise supported XDP features.Dimitri Daskalakis
Drivers are supposed to advertise the XDP features they support. This was missed while adding XDP support. Before: $ ynl --family netdev --dump dev-get ... {'ifindex': 3, 'xdp-features': set(), 'xdp-rx-metadata-features': set(), 'xsk-features': set()}, ... After: $ ynl --family netdev --dump dev-get ... {'ifindex': 3, 'xdp-features': {'basic', 'rx-sg'}, 'xdp-rx-metadata-features': set(), 'xsk-features': set()}, ... Fixes: 168deb7b31b2 ("eth: fbnic: Add support for XDP_TX action") Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Dimitri Daskalakis <dimitri.daskalakis1@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260218030620.3329608-1-dimitri.daskalakis1@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-02-19fbdev: au1100fb: Replace license boilerplate by SPDX headerUwe Kleine-König
This also gets rid of an old address of the FSF. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-02-19fbdev: au1100fb: Fold au1100fb.h into its only userUwe Kleine-König
This gets rid of a header that is only used once. The copyrights and license specifications are all already covered in the au1100fb.c file. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-02-19fbdev: au1100fb: Replace custom printk wrappers by pr_*Uwe Kleine-König
The global wrappers also have the advantage to do stricter format checking, so the pr_devel formats are also checked if DEBUG is not defined. The global variants only check for DEBUG being defined and not its actual value, so the #define to zero is dropped, too. There is only a slight semantic change as the (by default disabled) debug output doesn't contain __FILE__ any more. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-02-19fbdev: au1100fb: Make driver compilable on non-mips platformsUwe Kleine-König
The header asm/mach-au1x00/au1000.h is unused apart from pulling in <linux/delay.h> (for mdelay()) and <linux/io.h> (for KSEG1ADDR()). Then the only platform specific part in the driver is the usage of the KSEG1ADDR macro, which for the non-mips case can be stubbed. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-02-19fbdev: au1100fb: Use proper conversion specifiers in printk formatsUwe Kleine-König
%zu is the dedicated type for size_t. %d only works on 32bit architectures where size_t is typedef'd to be unsigned int. (And then the signedness doesn't fit, but `gcc -Wformat` doesn't stumble over this. Also the size of dma_addr_t is architecture dependent and it should be printkd using %pad (and the value passed by reference). This prepares allowing this driver to be compiled on non-mips platforms. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-02-19fbdev: au1100fb: Mark several local functions as staticUwe Kleine-König
This fixes several (fatal) compiler warnings à la drivers/video/fbdev/au1100fb.c:530:6: error: no previous prototype for ‘au1100fb_drv_remove’ [-Werror=missing-prototypes] 523 | void au1100fb_drv_remove(struct platform_device *dev) | ^~~~~~~~~~~~~~~~~~~ Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-02-19fbdev: au1100fb: Don't store device specific data in global variablesUwe Kleine-König
Using global data to store device specific data is a bad pattern that breaks if there is more than one device. So expand driver data and drop the global variables. While there is probably no machine that has two or more au1100fb devices, this makes the driver a better template for new drivers and saves some memory if there is no such bound device. bloat-o-meter reports (for ARCH=arm allmodconfig + CONFIG_FB_AU1100=y and ignoring the rename of the init function): add/remove: 1/4 grow/shrink: 2/2 up/down: 1360/-4800 (-3440) Function old new delta au1100fb_drv_probe 2648 3328 +680 $a 12808 13484 +676 au1100fb_drv_resume 404 400 -4 au1100fb_fix 68 - -68 au1100fb_var 160 - -160 fbregs 2048 - -2048 $d 9525 7009 -2516 Total: Before=38664, After=35224, chg -8.90% Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-02-19Merge tag 'asoc-fix-v7.0-rockchip-i2s-tdm' of ↵Takashi Iwai
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Additional Rockchip fix for v7.0 One more ASoC fix, for a regression with the Rockchip I2S TDM support on a number of platforms.
2026-02-19drbd: Replace deprecated strcpy with strscpyThorsten Blum
strcpy() has been deprecated [1] because it performs no bounds checking on the destination buffer, which can lead to buffer overflows. Replace it with the safer strscpy(). No functional changes. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strcpy [1] Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Reviewed-by: Christoph Böhmwalder <christoph.boehmwalder@linbit.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-02-19drbd: fix "LOGIC BUG" in drbd_al_begin_io_nonblock()Lars Ellenberg
Even though we check that we "should" be able to do lc_get_cumulative() while holding the device->al_lock spinlock, it may still fail, if some other code path decided to do lc_try_lock() with bad timing. If that happened, we logged "LOGIC BUG for enr=...", but still did not return an error. The rest of the code now assumed that this request has references for the relevant activity log extents. The implcations are that during an active resync, mutual exclusivity of resync versus application IO is not guaranteed. And a potential crash at this point may not realizs that these extents could have been target of in-flight IO and would need to be resynced just in case. Also, once the request completes, it will give up activity log references it does not even hold, which will trigger a BUG_ON(refcnt == 0) in lc_put(). Fix: Do not crash the kernel for a condition that is harmless during normal operation: also catch "e->refcnt == 0", not only "e == NULL" when being noisy about "al_complete_io() called on inactive extent %u\n". And do not try to be smart and "guess" whether something will work, then be surprised when it does not. Deal with the fact that it may or may not work. If it does not, remember a possible "partially in activity log" state (only possible for requests that cross extent boundaries), and return an error code from drbd_al_begin_io_nonblock(). A latter call for the same request will then resume from where we left off. Cc: stable@vger.kernel.org Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com> Signed-off-by: Christoph Böhmwalder <christoph.boehmwalder@linbit.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-02-19rds: tcp: fix uninit-value in __inet_bindTabrez Ahmed
KMSAN reported an uninit-value access in __inet_bind() when binding an RDS TCP socket. The uninitialized memory originates from rds_tcp_conn_alloc(), which uses kmem_cache_alloc() to allocate the rds_tcp_connection structure. Specifically, the field 't_client_port_group' is incremented in rds_tcp_conn_path_connect() without being initialized first: if (++tc->t_client_port_group >= port_groups) Since kmem_cache_alloc() does not zero the memory, this field contains garbage, leading to the KMSAN report. Fix this by using kmem_cache_zalloc() to ensure the structure is zero-initialized upon allocation. Reported-by: syzbot+aae646f09192f72a68dc@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=aae646f09192f72a68dc Tested-by: syzbot+aae646f09192f72a68dc@syzkaller.appspotmail.com Fixes: a20a6992558f ("net/rds: Encode cp_index in TCP source port") Signed-off-by: Tabrez Ahmed <tabreztalks@gmail.com> Reviewed-by: Charalampos Mitrodimas <charmitro@posteo.net> Reviewed-by: Allison Henderson <achender@kernel.org> Link: https://patch.msgid.link/20260217135350.33641-1-tabreztalks@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-02-19net/rds: Fix NULL pointer dereference in rds_tcp_accept_oneAllison Henderson
Save a local pointer to new_sock->sk and hold a reference before installing callbacks in rds_tcp_accept_one. After rds_tcp_set_callbacks() or rds_tcp_reset_callbacks(), tc->t_sock is set to new_sock which may race with the shutdown path. A concurrent rds_tcp_conn_path_shutdown() may call sock_release(), which sets new_sock->sk = NULL and may eventually free sk when the refcount reaches zero. Subsequent accesses to new_sock->sk->sk_state would dereference NULL, causing the crash. The fix saves a local sk pointer before callbacks are installed so that sk_state can be accessed safely even after new_sock->sk is nulled, and uses sock_hold()/sock_put() to ensure sk itself remains valid for the duration. Fixes: 826c1004d4ae ("net/rds: rds_tcp_conn_path_shutdown must not discard messages") Reported-by: syzbot+96046021045ffe6d7709@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=96046021045ffe6d7709 Signed-off-by: Allison Henderson <achender@kernel.org> Link: https://patch.msgid.link/20260216222643.2391390-1-achender@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-02-19s390/tape: Fix device driver nameJan Höppner
Recent cleanups and code consolidations in the s390 tape device driver renamed files and function namespaces from tape_34xx to tape_3490 to better reflect the single support of the IBM 3490E device in the codebase. These changes also renamed the driver name to tape_3490, which consequently broke userspace as the sysfs driver path is now /sys/bus/ccw/drivers/tape_3490/ instead of /sys/bus/ccw/drivers/tape_34xx/. Change the device driver name back to tape_34xx to fix userspace. Fixes: 9872dae6102e ("s390/tape: Rename tape_34xx.c to tape_3490.c") Reported-by: Alexander Egorenkov <egorenar@linux.ibm.com> Reviewed-by: Jens Remus <jremus@linux.ibm.com> Tested-by: Alexander Egorenkov <egorenar@linux.ibm.com> Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2026-02-19io_uring: Add size check for sqe->cmdGovindarajulu Varadarajan
For SQE128, sqe->cmd provides 80 bytes for uring_cmd. Add macro to check if size of user struct does not exceed 80 bytes at compile time. User doesn't have to track this manually during development. Replace io_uring_sqe_cmd() inline func with macro and add io_uring_sqe128_cmd() which checks struct size for 16 bytes cmd and 80 bytes cmd respectively. Signed-off-by: Govindarajulu Varadarajan <govind.varadar@gmail.com> Reviewed-by: Caleb Sander Mateos <csander@purestorage.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-02-19io_uring: add IORING_OP_URING_CMD128 to opcode checksCaleb Sander Mateos
io_should_commit(), io_uring_classic_poll(), and io_do_iopoll() compare struct io_kiocb's opcode against IORING_OP_URING_CMD to implement special treatment for uring_cmds. The recently added opcode IORING_OP_URING_CMD128 is meant to be equivalent to IORING_OP_URING_CMD, so treat it the same way in these functions. Fixes: 1cba30bf9fdd ("io_uring: add support for IORING_SETUP_SQE_MIXED") Signed-off-by: Caleb Sander Mateos <csander@purestorage.com> Reviewed-by: Anuj Gupta <anuj20.g@samsung.com> Reviewed-by: Kanchan Joshi <joshi.k@samsung.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-02-19Merge branch 'i2c/i2c-host-2' of ↵Wolfram Sang
git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux into i2c/for-mergewindow
2026-02-19arm64: hugetlbpage: avoid unused-but-set-parameter warning (gcc-16)Arnd Bergmann
gcc-16 warns about an instance that older compilers did not: arch/arm64/mm/hugetlbpage.c: In function 'huge_pte_clear': arch/arm64/mm/hugetlbpage.c:369:57: error: parameter 'addr' set but not used [-Werror=unused-but-set-parameter=] The issue here is that __pte_clear() does not actually use its second argument, but when CONFIG_ARM64_CONTPTE is enabled it still gets updated. Replace the macro with an inline function to let the compiler see the argument getting passed down. Suggested-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Dev Jain <dev.jain@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-02-19arm64: Force the use of CNTVCT_EL0 in __delay()Marc Zyngier
Quentin forwards a report from Hyesoo Yu, describing an interesting problem with the use of WFxT in __delay() when a vcpu is loaded and that KVM is *not* in VHE mode (either nVHE or hVHE). In this case, CNTVOFF_EL2 is set to a non-zero value to reflect the state of the guest virtual counter. At the same time, __delay() is using get_cycles() to read the counter value, which is indirected to reading CNTPCT_EL0. The core of the issue is that WFxT is using the *virtual* counter, while the kernel is using the physical counter, and that the offset introduces a really bad discrepancy between the two. Fix this by forcing the use of CNTVCT_EL0, making __delay() consistent irrespective of the value of CNTVOFF_EL2. Reported-by: Hyesoo Yu <hyesoo.yu@samsung.com> Reported-by: Quentin Perret <qperret@google.com> Reviewed-by: Quentin Perret <qperret@google.com> Fixes: 7d26b0516a0d ("arm64: Use WFxT for __delay() when possible") Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/ktosachvft2cgqd5qkukn275ugmhy6xrhxur4zqpdxlfr3qh5h@o3zrfnsq63od Cc: stable@vger.kernel.org Signed-off-by: Will Deacon <will@kernel.org>
generated by cgit v1.2.3 (git 2.46.0) at 2026-05-19 17:29:31 +0000